Skip site navigation (1) Skip section navigation (2)

Re: TABLE-function patch vs plpgsql

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: TABLE-function patch vs plpgsql
Date: 2008-07-29 17:10:24
Message-ID: 1217351424.8386.9.camel@huvostro (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)krosing(dot)net> writes:
> > Why is PROARGMODE_TABLE needed at all ?
> 
> Personally I would rather not have it, but Pavel insists it's needed
> for standards compliance in PL/PSM, where output TABLE columns are not
> supposed to have names visible within the function.

Why not just hide the names from PL/PSM ?

The current way seems to just add complexity for no good reason.

> One reason to have it is so we can distinguish the correct way to
> reverse-list an output parameter (as OUT or as a table result column).
> Although we could equally well solve that with an extra bool column in
> pg_proc instead of redefining proargmodes, as long as you're willing to
> accept the reasonable restriction that you can't mix the two styles of
> declaring output parameters. 

Can you mix them with current API ? what would that mean ?

I mean, does the _caller_ ofd the function need to distinguisd OUT and
TABLE returns ?

>  In principle PL/PSM could look at such a
> bool too, so there's more than one way to do it.

Yup, I'd prefer that.

> The feeling I had about it was that if we were adding
> PROARGMODE_VARIADIC in 8.4 then there wasn't any very strong argument
> not to add PROARGMODE_TABLE; any code looking at proargmodes is going
> to need updates anyway.

I missed the addition PROARGMODE_VARIADIC too. 

Has it already been added ?

What is it supposed to do ?

----------------
Hannu



In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-07-29 17:23:47
Subject: Re: Python 2.5 vs the buildfarm
Previous:From: Greg SmithDate: 2008-07-29 17:03:35
Subject: Re: Python 2.5 vs the buildfarm

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group