Re: WIP: Allow SQL-language functions to reference parameters by parameter name

On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan <andrew(at)dunslane(dot)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