On 04/07/2011 09:58 PM, Tom Lane wrote:
Robert Haas<robertmh...@gmail.com> writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan<and...@dunslane.net> wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on warts such as $varname that are
completely at odds with the style of the rest of the language. That doesn't
do anything except produce a mess.
Well, what it does is avoid breaking compatibility with previous
versions of PostgreSQL. I think that actually does have some value.
Otherwise, we'd be folding to upper-case by default.
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers