Re: proposal sql: labeled function params - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: proposal sql: labeled function params
Date
Msg-id 1218824447.7387.13.camel@huvostro
Whole thread Raw
In response to Re: proposal sql: labeled function params  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal sql: labeled function params
Re: proposal sql: labeled function params
List pgsql-hackers
On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Random googling shows me that Oracle appears to use a syntax like
> >     name => value
> > This is actually a feature that I would like to see implemented soonish, so if 
> > anyone has input on the possible syntax consequences, please comment.
> 
> We've been over this territory before.  The problem with "name => value"
> is that it requires reserving a perfectly good user-defined operator name.

We could declare, that using operator => in function argument expression
requires parenthesis : func( a => (b => c) means param a with value
expression (b => c) nad just func((b => c)) means first param with value
(b=>c)

the main use of named params is calling functions with default values,
and giving some params. there I'm more concerned about default args and
rules for finding right function in presence of functions with both
multiple args and default values for some.

create function f(a int) ...

create function f(a int, b int default 7) 

create function f(text text)

and then calling f(4) - which one would it call

what about f('4')

Of course, we could also have default values without named params, and
just require keyword DEFAULT where we want default value :)

> "value AS name", on the other hand, accomplishes the same in a more
> SQL-looking fashion with no new reserved word (since AS is already
> fully reserved).

would it be more natural / SQL-like to use "value AS name" or "name AS
value" ?

-------------
Hannu




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies
Next
From: Bruce Momjian
Date:
Subject: Re: Automatic Client Failover