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

Re: TABLE-function patch vs plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)krosing(dot)net>
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 16:46:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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.  In principle PL/PSM could look at such a
bool too, so there's more than one way to do it.

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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Asko OjaDate: 2008-07-29 16:48:16
Subject: Re: TABLE-function patch vs plpgsql
Previous:From: Hannu KrosingDate: 2008-07-29 16:27:27
Subject: Re: TABLE-function patch vs plpgsql

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