Re: proposal sql: labeled function params

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Decibel! <decibel(at)decibel(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: proposal sql: labeled function params
Date: 2008-08-20 10:38:11
Message-ID: 162867790808200338k42d475b6rc3557d68e4aefc55@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

I understand now why Oracle use => symbol for named params. This isn't
used so operator - so implementation is trivial.

postgres=# create function x(a boolean) returns bool as $$select $1$$
language sql;
CREATE FUNCTION
Time: 5,549 ms
postgres=# select x(a => true);
x
---
t
(1 row)

Time: 0,566 ms
postgres=# select x(a => 0 >= 1);
x
---
f
(1 row)

Time: 0,772 ms
postgres=# select x(a => 0 <= 1);
x
---
t
(1 row)

Time: 0,633 ms
postgres=# select x(a => 0 <= 1);

it could live together with labels
postgres=# select x(a => 0 <= 1 as boo);
x
---
t
(1 row)

there are not any conflict. nice (operator => is never used).

I dislike to use AS for named params - it has some unhappy consequences:
a) it merge two features together (named params, labels),
b) when we disable @a, then we should implement only one feature - named params
c) @b isn't compatible with SQL/XML that is implemented now

I don't found any notice about db2 default parameters.

Named params needs different algorithm of searching in pg_proc. There
should be some new problems - like

create function foo(a integer, b integer);
select foo(10,10); -- ok
select foo(a => 10, b =>20); -- ok
select foo(b=>20, a =>20); -- ok
select foo(c=>20, 20); -- unknown fce !!!

Regards
Pavel Stehule

real gram implemenation:
param_list: param
{
$$ = list_make1($1);
}
| param_list ',' param
{
$$ = lappend($1, $3);
}
;

param:
a_expr
{
$$ = $1;
}
| param_name POINTER a_expr
{
$$ = $3;
}
| a_expr AS ColLabel
{
$$ = $1;
}
| param_name POINTER a_expr AS ColLabel
{
$$ = $3;
}
;

lexer
identifier {ident_start}{ident_cont}*

typecast "::"
pointer "=>"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Weimer 2008-08-20 10:49:34 Re: Is mdextend really safe?
Previous Message Gregory Stark 2008-08-20 09:51:14 Is mdextend really safe?