2011/4/5 Peter Eisentraut <pete...@gmx.net>:
> On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
>> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut <pete...@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.)
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.
>
>
>
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
