On 7/18/08, Tom Lane <[EMAIL PROTECTED]> 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. > Here are some reasons: > > 1. It's ludicrous to argue that "standards compliance" requires the > behavior-as-submitted. plpgsql is not specified by the SQL standard.
Yes, but it would be a good feature addition to plpgsql. Currently there is no way to suppress the local variable creation. The proposed behaviour would give that possibility. > 2. Not having the parameter names available means that you don't have > access to their types either, which is a big problem for polymorphic > functions. Read the last couple paragraphs of section 38.3.1: > > http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES > as well as the following 38.3.2. How would you do those things with > a polymorphic TABLE column? This does not make sense as Postgres does not support polymorphic table columns... For polymorphic function arguments user should use OUT parameters. I think thats the point - it should not be just syntactic sugar for OUT parameters, let it be different. > 3. Not treating the parameters as assignable variables makes RETURN NEXT > nearly worthless in a TABLE function. Since they're not assignable, > you can't use the parameterless form of RETURN NEXT (which'd return > the current values of the variables). The only alternative available > is to return a record or row variable; but there's no convenient way > to declare such a variable, since after all the whole point here is > that the function's output rowtype is anonymous. > > 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. What other PLs do create local variables for OUT parameters? > If we insist on the current definition then we are eventually going to > need to kluge up some solutions to #2 and #3, which seems like make-work > to me when we already have smooth solutions to these problems for > OUT parameters. > > Comments? I would prefer - no local vars, no polymorphism and funcname%rowtype. Some functions are better written with OUT parameters but some with record variable for return rows. The new behaviour would allow picking best coding style for a function. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
