1. 

   Shamgar, Member

   I've only been using mydbr for a couple of days, but I'm hooked already. I had a whole evening at home to myself and ended up spending it all on writing new reports. This is soooo much better than the hacked together reporting I've been doing.

   That having been said, some of the data I would most like to build reports around is stored in a postgresql database, and that is vendor enforced. I do have some tools I built to pull some data out of it and store it in a mysql database for a couple of one-off reports, but that's not really a scalable solution.

   Do you guys have support for postgresql on the roadmap anywhere?
2. 

   myDBR Team, Key Master

   Glad you like myDBR. Now that we got 1.4 out, you could like it even more.

   We would love to support PostgreSQL, but it would currently require bit of redesign how myDBR works. Reasons are purely technical.

   PostgreSQL stored procedure support is bit different than the one you can find on some other databases (MySQL. MS SQL, Sybase etc). In our understanding, PostgreSQL's support for things like multiple result set's inside a procedure is more limited. There are some workarounds that one could take (use of refcursor etc), but fundamentally PostgreSQL stored procedures are more like functions and therefore not quite suitable for the idea what myDBR is based on.

   --
   myDBR Team
3. 

   Shamgar, Member

   Good to know.
4. 

   TJH, Member

   Hi,

   I just want to say that we haven really taken to MyDBR and love its simplicity and flexibility.

   However, we are starting to look at Postgres to back our application and move away from MySQL. Of course we would not want to lose MyDBR.

   Does even Postgres' support of functions returning SETOF REFCURSUR not sufficient for MyDBR?

   Admittedly, it's a bit goofy. And this example from the PG docs doesn't indicate that you don't have to pass the refcursor name as an in-parameter. You can declare function-local variables and return those.

   PG will return automatically named refcursors to the client. Your client just needs to know how to enumerate/iterate.

   Admittedly, I don't know the other implementation issues around adding a new DBMS, but I wanted to check-in and see if PG support was still being pursued at all.

   Many thanks for a wonderful product,
   Trevor

   CREATE FUNCTION myfunc(refcursor, refcursor) RETURNS SETOF refcursor AS $$ BEGIN OPEN $1 FOR SELECT * FROM table_1; RETURN NEXT $1; OPEN $2 FOR SELECT * FROM table_2; RETURN NEXT $2; END; $$ LANGUAGE plpgsql;

   -- need to be in a transaction to use cursors. BEGIN;

   SELECT * FROM myfunc('a', 'b');

   FETCH ALL FROM a; FETCH ALL FROM b; COMMIT;
5. 

   myDBR Team, Key Master

   Postgres' support of stored procedures (functions) is so different than the standard stored procedures that it would require considerable effort to be supported.

   Easiest way to use myDBR with Postgres is to use MS SQL Server / free SQL Server Express as a reporting database and use MS SQL Server's linked server-feature to talk to Postgres.

   --
   myDBR Team

Reply

You must log in to post.