Skip site navigation (1) Skip section navigation (2)

Re: functional call named notation clashes with SQL feature

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
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-26 22:52:33
Message-ID: (view raw or flat)
Lists: pgsql-hackers

Peter Eisentraut wrote:
> 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).
> Seems kind of bad to overload this with something completely different.
> What should we do?

I think we should fix it now.  Quick thought: maybe we could use FOR 
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's 
mechanism for this is 'paramname => value', but I think that has 
problems because of our possibly use of => as an operator - otherwise 
that would be by far the best way to go.



In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-05-26 22:58:06
Subject: Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT
Previous:From: Simon RiggsDate: 2010-05-26 22:52:04
Subject: Re: Keepalive for max_standby_delay

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group