On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mar 25, 2011, at 7:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Well, maybe, but it's not like it's subtle or hard to fix.
>
>> Depends how much of it you have. I've become very skeptical of
>> anything that breaks pg_dump-and-reload-ability.
>
> This wouldn't break pg_dump scripts, because they disable
> check_function_bodies. You would get a failure on first *use*
> of a function, which is something different.
>
> Basically my concern here is that in the name of easing a short-term
> conversion issue, we'll be condemning users to a future of subtle,
> hard-to-find bugs due to ambiguous names. How many hundreds of
> reports have we seen about the equivalent problem in plpgsql?
>
> You could argue that the frequency of plpgsql issues was at least partly
> due to having a poor choice of which way to resolve the ambiguity, but
> I don't think it can be entirely blamed on that.
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
or &&foo!!$#? to mean "the parameter called foo", then this would all
be a non-issue.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company