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

2011/4/5 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> 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(at)gmx(dot)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.)

This is a good design. If we disallow a ambiguities, there isn't a
space for bugs. And if anybody needs to accent any parameter, then
there are still $n notation.

There is lot of notation and I don't think so it is necessary to add new one

MySQL, MSSQL uses @, DB2, ANSI SQL no prefix, Oracle and Firebird uses
":", but in different context.

simply - chaos.

There was request for some alias on function name. It could be.
PL/pgSQL knows a #option, so there can be some similar in SQL.

CREATE OR REPLACE FUNCTION longnamefunc(param integer)
RETURNS ... AS $$
#alias longnamefunc ln
SELECT ln.param;
$$

Regards

Pavel Stehule

>
> 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.
>
>
>
>