2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>: > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote: >> I've been working on the TABLE-function patch, and I am coming to the >> conclusion that it's really a bad idea for plpgsql to not associate >> variables with output columns --- that is, I think we should make >> RETURNS TABLE columns semantically just the same as OUT parameters. > > I just looked at recent cahnges in pl/python, and found out that RETURNS > TABLE is _NOT_ semantically just the same as OUT parameters, at least at > API level. > > Why can't it be ? > > Why is PROARGMODE_TABLE needed at all ?
because I need to separate classic OUT args from table args. TABLE function has more clean syntax, then our SRF functions, and it isn't related only to SQL/PSM. It works nice together with SQL language. Actually TABLE variables are exactly same as OUT variables (in plpgsq), that is possible, but I am not sure, if it's best too. I have prototype where is possible declare variables derivated from function return type create function foo(..) returns table(x int, y int) as $$ declare result foo%rowtype; resx foo.x%type; .... all this has to minimalist risk of variables and sql object name collisions. Regards Pavel Stehule > >> 4. It's a whole lot easier to explain things if we can just say that >> OUT parameters and TABLE parameters work alike. This is especially >> true when they actually *are* alike for all the other available PLs. > > It would be nice, if they were the same at API level as well. > > -------------------- > Hannu > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
