Re: TABLE-function patch vs plpgsql
От | Tom Lane |
---|---|
Тема | Re: TABLE-function patch vs plpgsql |
Дата | |
Msg-id | 12107.1217350008@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: TABLE-function patch vs plpgsql (Hannu Krosing <hannu@krosing.net>) |
Ответы |
Re: TABLE-function patch vs plpgsql
|
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: