On Thu, Apr 14, 2011 at 1:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
>> <dimitri@2ndquadrant.fr> wrote:
>>> Unless we make it so that no such version ever exists. Meaning that the
>>> code works fine as is or using WHERE id = developer_lookup.id. AS id
>>> can't ever be the parameter in this case, you're just fine.
>>>
>>> Bearing in mind that $1 etc shortcuts still are available, I don't
>>> really see this qualification of parameter names with function names so
>>> big a problem that we should find a way to avoid it and risk breaking
>>> compatibility.
>>>
>>> Don't forget that any ambiguity here will mean *huge* migration costs.
>
>> If I'm reading your email correctly, we're in agreement.
>
> Hmm, what I read Dimitri to be proposing is that we *require* parameter
> names to be qualified with the function name. I don't recall hearing
> that before. It would solve the problem perhaps, but I think the moans
> and groans will be numerous.
So far the most promising proposal I've seen seems to be to let id
mean the parameter called id only when it can't refer to anything in
the query.
Tabula raza, I'd prefer your proposal to make any ambiguity an error,
but it's not worth the breakage. I'd be fine with having a way to
explicitly request that behavior though, a la Perl's "use strict".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
