Re: TABLE-function patch vs plpgsql - Mailing list pgsql-hackers

<div dir="ltr">Tom> RETURNS TABLE columns semantically just the same as OUT parameters.<br /><br />I hope you are
notproposing to create another case of crippled OUT parameters that are quite problematic to use together with inline
sqlor has it gotten fixed on the road (we are still using 8.2 on most of our servers).<br /><br /><div
class="gmail_quote">OnFri, Jul 18, 2008 at 2:13 AM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I've been working on
theTABLE-function patch, and I am coming to the<br /> conclusion that it's really a bad idea for plpgsql to not
associate<br/> variables with output columns --- that is, I think we should make<br /> RETURNS TABLE columns
semanticallyjust the same as OUT parameters.<br /> Here are some reasons:<br /><br /> 1. It's ludicrous to argue that
"standardscompliance" requires the<br /> behavior-as-submitted.  plpgsql is not specified by the SQL standard.<br /><br
/>2. Not having the parameter names available means that you don't have<br /> access to their types either, which is a
bigproblem for polymorphic<br /> functions.  Read the last couple paragraphs of section 38.3.1:<br /><a
href="http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES"
target="_blank">http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES</a><br
/>as well as the following <a href="http://38.3.2." target="_blank">38.3.2.</a>  How would you do those things with<br
/>a polymorphic TABLE column?<br /><br /> 3. Not treating the parameters as assignable variables makes RETURN NEXT<br
/>nearly worthless in a TABLE function.  Since they're not assignable,<br /> you can't use the parameterless form of
RETURNNEXT (which'd return<br /> the current values of the variables).  The only alternative available<br /> is to
returna record or row variable; but there's no convenient way<br /> to declare such a variable, since after all the
wholepoint here is<br /> that the function's output rowtype is anonymous.<br /><br /> 4. It's a whole lot easier to
explainthings if we can just say that<br /> OUT parameters and TABLE parameters work alike.  This is especially<br />
truewhen they actually *are* alike for all the other available PLs.<br /><br /> If we insist on the current definition
thenwe are eventually going to<br /> need to kluge up some solutions to #2 and #3, which seems like make-work<br /> to
mewhen we already have smooth solutions to these problems for<br /> OUT parameters.<br /><br /> Comments?<br /><br />
Forthe archives, here is the patch as I currently have it (with the<br /> no-plpgsql-variables behavior).  But unless I
heara good argument<br /> to the contrary, I'm going to change that part before committing.<br /><br />                
      regards, tom lane<br /><br /><br /><br /> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/><br /></blockquote></div><br /></div>