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: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Merlin Moncure <mmoncure@gmail.com>, Peter Eisentraut <peter_e@gmx.net>, "David E. Wheeler" <david@kineticode.com>, Matthew Draper <matthew@trebex.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2011-04-08T14:53:27Z
Lists: pgsql-hackers
Hello

>>
>> Well, if we're going to consider 100% backwards compatibility a "must",
>> then we should just stick with what the submitted patch does, ie,
>> unqualified names are matched first to query columns, and to parameters
>> only if there's no column match.  This is also per spec if I interpreted
>> Peter's comments correctly.  The whole thread started because I
>> suggested that throwing an error for ambiguous cases might be a better
>> design in the long run, but apparently long term ease of code
>> maintenance is far down our list of priorities ...
>>
>>
>
> I think the discussion went off into the weeds somewhat, and I'm guilty of
> responding to suggestions that don't refer to the original subject.
>
> For SQL language functions, I think you're right. The only caveat I have is
> that if your function name is very long, having to use it as a
> disambiguating qualifier can be a bit ugly.

same mechanism works well in plpgsql and nobody requested a some
special shortcut.

Regards

Pavel

>
> cheers
>
> andrew
>