Re: TABLE-function patch vs plpgsql
От | Hannu Krosing |
---|---|
Тема | Re: TABLE-function patch vs plpgsql |
Дата | |
Msg-id | 1217351424.8386.9.camel@huvostro обсуждение исходный текст |
Ответ на | Re: TABLE-function patch vs plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TABLE-function patch vs plpgsql
|
Список | pgsql-hackers |
On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote: > Hannu Krosing <hannu@krosing.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
В списке pgsql-hackers по дате отправления: