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 >