From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TABLE-function patch vs plpgsql |
Date: | 2008-07-18 08:22:30 |
Message-ID: | e51f66da0807180122s71a1613bj2436fa45200e515a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/18/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paesold | 2008-07-18 08:39:23 | Re: PATCH: CITEXT 2.0 v4 |
Previous Message | Simon Riggs | 2008-07-18 07:52:55 | Re: [PATCH]-hash index improving |