On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
> On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmh...@gmail.com> writes:
> >> On Mar 25, 2011, at 7:45 PM, Tom Lane <t...@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.
How about psql's :foo syntax?
Cheers,
David.
--
David Fetter <da...@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
