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. 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? 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. 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? For the archives, here is the patch as I currently have it (with the no-plpgsql-variables behavior). But unless I hear a good argument to the contrary, I'm going to change that part before committing. regards, tom lane
binCGdzCdrRxb.bin
Description: table-func-2.patch.gz
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers