On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane <t...@sss.pgh.pa.us> 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 ...
Not really. But if you're going to shout down my proposal because it's not in the spec, then it's a bit hard to see how you can argue that we should implement your non-spec-compliant behavior instead, especially at the cost of a painful backward compatibility break. I actually am 100% in agreement with you that allowing ambiguous references to resolve either way is a recipe for bugs, bugs, and more bugs. But breaking people's code is not a better answer. We still have people on 8.2 because the pain of upgrading to 8.3 is more than they can bear, and how many releases have we spent trying to get standard_conforming_strings worked out? I admit this probably wouldn't be as bad, but we've managed to put out several releases in a row now that are relatively painless to upgrade between, and I think that's a trend we should try to keep going. I am halfway tempted to say that we need to invent our own procedural language that is designed not for compatibility with the SQL standard or Oracle, but for non-crappiness. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers