Re: functional call named notation clashes with SQL feature

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: functional call named notation clashes with SQL feature
Date: 2010-05-27 08:29:22
Message-ID: AANLkTik7a_EUpx15NU0N8tjuzdix6CpodX0dSxOSqRMH@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/5/26 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> It turns out that the SQL standard uses the function call notation
>
> foo(this AS that)
>
> for something else:
>
> <routine invocation> ::= <routine name> <SQL argument list>
>
> <routine name> ::= [ <schema name> <period> ] <qualified identifier>
>
> <SQL argument list> ::= <left paren> [ <SQL argument> [ { <comma> <SQL
> argument> }... ] ] <right paren>
>
> <SQL argument> ::= <value expression>
> | <generalized expression>
> | <target specification>
>
> <generalized expression> ::= <value expression> AS <path-resolved
> user-defined type name>
>
> In systems that have inheritance of composite types, this is used to
> specify which type the value is supposed to be interpreted as (for
> example, to treat the value as a supertype).
>

can it be used (in ANSI SQL semantic) as cast?

like SELECT foo(10.33 AS int)

> Seems kind of bad to overload this with something completely different.
> What should we do?
>
>

Is ANSI SQL consistent in this syntax? SQL/XML use "AS" in different meaning.

Regards
Pavel

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-05-27 09:01:04 Re: Synchronization levels in SR
Previous Message Peter Eisentraut 2010-05-27 08:15:29 Re: functional call named notation clashes with SQL feature