Re: [SQL] dynamic OUT parameters?

2009-02-01 Thread Pavel Stehule
Hello

try to look on

http://okbob.blogspot.com/2008/08/using-cursors-for-generating-cross.html

regards
Pavel Stehule

2009/2/1 Ivan Sergio Borgonovo :
> On Sun, 01 Feb 2009 12:42:12 +0900
> Craig Ringer  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
>

-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql


Re: [SQL] dynamic OUT parameters?

2009-02-01 Thread Ivan Sergio Borgonovo
On Sun, 01 Feb 2009 12:42:12 +0900
Craig Ringer  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