Re: TABLE-function patch vs plpgsql

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