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
>
