On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote: > 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.
I read your explanation, and I still don't understand, why can't TABLE and SETOF RECORD + OUT args be just different spellings of the same thing. Is there a scenario, where both are needed in the same function ? > TABLE function has more clean syntax, then our SRF functions, True. But why is separation on C API level needed ? > 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. Still I have the same question - What is the difference ? > 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; .... I still don't see, why the same thing can't work on create function foo(OUT x int, OUT y int) returns setof record as $$ declare result foo%rowtype; resx foo.x%type; ... > all this has to minimalist risk of variables and sql object name collisions. Are there any cases, where TABLE functions and OUT + returns SETOF RECORD functions are _called_ differently ? ------------------ Hannu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
