Re: TABLE-function patch vs plpgsql

On 7/18/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Marko Kreen" <markokr(at)gmail(dot)com> writes:
> > On 7/18/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> >> 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.
>
> Why would anyone consider that a "feature"?

Well, it's issue of "big global namespace" vs. "several local namespaces"

If you have function that has lot of OUT parameters and also
local variables it gets confusing fast. It would be good to avoid
OUT parameters polluting local variable space.

> >> 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.
>
> > This does not make sense as Postgres does not support
> > polymorphic table columns...
>
> No, but it certainly supports polymorphic function output parameters,
> and that's what these really are.

I was referring to the syntax of the feature: "RETURNS TABLE"

> > I think thats the point - it should not be just syntactic sugar for
> > OUT parameters, let it be different.
>
> Why? All you're doing is proposing that we deliberately cripple
> the semantics.

plpgsql already is rather crippled, we could use that feature
to give additional flexibility to it.

--
marko