On Sun, 01 Feb 2009 12:42:12 +0900
Craig Ringer <cr...@postnewspapers.com.au> wrote:
> gher...@fmed.uba.ar wrote:
>
> > Well, aparenty my problem remains, because the boss want that the
> > programmers just need to call
> > select * from report('table_name').
>
> Then, AFAIK, you're not going to have much luck, as Pg needs to
> know the columns that'll be output before the function is called.
> Applications and DB access interfaces also usually also need to
> know the column list beforehand.
>
> If you return a refcursor you can at least use:
>
> SELECT report('table_name');
> FETCH ALL IN 'cursorname';
>
> The documentation has a more full example:
>
> http://www.postgresql.org/docs/8.2/interactive/plpgsql-cursors.html#AEN40465
>
> Personally, I find it difficult to imagine what could be wrong
> with that.
I've followed this thread with interest.
I'm starting to manage larger and larger code base of plpsql.
What I find hard to achieve is code reuse and implication of some
techniques to performances.
I didn't see many examples that exploit cursors around.
Does anyone have some pointer to some more enlightening use of
cursors for code reuse and OOP?
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
