Re: WIP: Allow SQL-language functions to reference parameters by parameter name

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Matthew Draper <matthew@trebex.net>, pgsql-hackers@postgresql.org
Date: 2011-03-25T20:08:24Z
Lists: pgsql-hackers
2011/3/25 Tom Lane <tgl@sss.pgh.pa.us>:
> Matthew Draper <matthew@trebex.net> writes:
>> Attached is a WIP patch that allows SQL-language functions to reference
>> their parameters by name.
>
>> It uses p_post_columnref_hook, so potentially ambiguous references
>> prefer the column... that seems to make the most sense, both because it
>> avoids a backwards incompatibility, and it conforms with SQL's usual
>> notion of assuming you mean the "nearest" name.
>
> Personally I'd vote for *not* having any such dangerous semantics as
> that.  We should have learned better by now from plpgsql experience.
> I think the best idea is to throw error for ambiguous references,
> period.  That means you do need ways to disambiguate in both directions.
> For column references you can just qualify with the table name/alias.
> If the parameter reference is intended, allow qualification with the
> function name.

I agree with Tom.

There can be GUC for controlling use or don't use a parameter names. I
am for GUC, because there will be a bilion conflicts. But a talk about
priorities - sql identifier or parameter is useless.

Regards

Pavel Stehule

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>