proposal - function's default parametes - Mailing list pgsql-hackers

From Pavel Stehule
Subject proposal - function's default parametes
Date
Msg-id 162867790809171324y500ae5a4yb91d9de144b33a7a@mail.gmail.com
Whole thread Raw
List pgsql-hackers
Hello,

before any implementation of named params we have to implement
parameters with default values. I don't see any sense of named params
without it. It's ortogonal to variadic functions (variadic functions
are called when we put more parameters than functions has, dafault
parameters are used when we put less parameters than funtions has).
Similar implementation has firebird. Default values are filled from
right -

create function foo(undefvar type, var1 type1 = expr1, var2 type2 =
expr2, ... var_n type_n = expr_n)

select foo(cexpr1, cexpr2) is transformed to

select foo(cexpr1, cexpr2, expr2, ... expr_n)

Problems with identification of good function are same as with
variadic functions.

Implementation:
In my prototype I used special datatype: position_expression that
carries position and parsed and transformed expression. pg_proc has
new column "defaults" of position_expression[] type. Position will be
used for named params in future, and using this type protect us to
compatibility problems.

postgres=# create or replace function x1(int = 1,int = 2,int= 3)       returns int as $$         select $1+$2+$3;
$$language sql;
 
CREATE FUNCTION
postgres=# select x1();
x1
----
6
(1 row)

postgres=# select x1(10);;
x1
----
15
(1 row)

postgres=# select x1(10,20);
x1
----
33
(1 row)

postgres=# select x1(10,20,30);
x1
----
60
(1 row)

This feature is implemented on SQL level, so all PL languages will be supported.

any comments, ideas are welcome

regards
Pavel Stehule


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: Autovacuum and Autoanalyze
Next
From: Alvaro Herrera
Date:
Subject: optimizing CleanupTempFiles