Re: WIP: Allow SQL-language functions to reference parameters by parameter name - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id 1302031980.27487.37.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Merlin Moncure <mmoncure@gmail.com>)
Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
> >> +1 on using $foo.  Even with the standardization risk I think it's the
> >> best choice. Prefer $"foo" to ${foo} though.
> >
> > What standardization risk?  The standard has already existed for >10
> > years and is widely implemented.
> 
> What is the standard, and who is it that has implemented it that way?

As mentioned earlier, see under clause on <identifier chain>.  The
summary is that in
   CREATE FUNCTION foo(a int)

you can refer to the parameter as either of
   a   foo.a

with some scoping rules to resolve ambiguities with column references.
(These are essentially the same scoping rules that tell you what "a"
refers to when you have multiple tables with an "a" column in a query.)

As far as I can tell, the syntax is implemented, more or less, at least
in Oracle, DB2, MySQL, Firebird, and HSQL.  I haven't checked what they
do with the scoping rules, of course.





pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Next
From: Merlin Moncure
Date:
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name