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

On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
> On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Mar 25, 2011, at 7:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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