Обсуждение: Function sugnature with default parameter
Hello,
I find default values confusing when a function is overloaded, below is an example.
CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1, C INT DEFAULT 1) RETURNS INT AS
$$
BEGIN
RETURN a+b+c;
END;
$$
LANGUAGE 'plpgsql';
CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1) RETURNS INT AS
$$
BEGIN
RETURN a+b;
END;
$$
LANGUAGE 'plpgsql';
$$
BEGIN
RETURN a+b+c;
END;
$$
LANGUAGE 'plpgsql';
CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1) RETURNS INT AS
$$
BEGIN
RETURN a+b;
END;
$$
LANGUAGE 'plpgsql';
-- this will fail
--SELECT default_test(1,3);
--SELECT default_test(1);
test=# \df default_test
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+--------------+------------------+---------------------------------------------------------------+--------
public | default_test | integer | a integer DEFAULT 1, b integer DEFAULT 1 | normal
public | default_test | integer | a integer DEFAULT 1, b integer DEFAULT 1, c integer DEFAULT 1 | normal
(2 rows)
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+--------------+------------------+---------------------------------------------------------------+--------
public | default_test | integer | a integer DEFAULT 1, b integer DEFAULT 1 | normal
public | default_test | integer | a integer DEFAULT 1, b integer DEFAULT 1, c integer DEFAULT 1 | normal
(2 rows)
SELECT default_test(1,3, DEFAULT); -- match function number 1
SELECT default_test(1,3); -- match the function number 2
SELECT default_test(1); -- ERROR
salah jubeh wrote > Hello, > > I find default values confusing when a function is overloaded, below is an > example. > > > CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1, > C INT DEFAULT 1) RETURNS INT AS > $$ > BEGIN > RETURN a+b+c; > END; > $$ > LANGUAGE 'plpgsql'; Provide a real use-case for this need and maybe someone will consider it worthwhile to implement. In the meantime use VARIADIC or define only the longest-default signature and provide reasonable default values for all optional arguments. In this case the defaults should be zero, not one. Or don't make any of the arguments DEFAULT and provide as many overloads as you use. The whole point of DEFAULT was to avoid having to do this for simple cases - you are not compelled to use default values if your use-case is too complex for them. Or just avoid overloading and use different names that describe better what the different versions accomplish. Specifying "DEFAULT" in the function call seems to defeat the point. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Function-sugnature-with-default-parameter-tp5793737p5793739.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
On 02/26/2014 10:15 AM, salah jubeh wrote: > I think, there is a difference between optional parameters and default parameter values. So, my suggestion would be somethinglike this. > SELECT default_test(1,3, DEFAULT); -- match function number 1 > > SELECT default_test(1,3); -- match the function number 2 > > SELECT default_test(1); -- ERROR > Regards This would break at least 4 major applications which I personally have worked on, and the benefit to users is unclear at best. One of the main reasons to *have* default parameters is to allow adding new parameters to existing functions without breaking old application code. So, -1 from me. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 02/26/2014 01:51 PM, Josh Berkus wrote:
> On 02/26/2014 10:15 AM, salah jubeh wrote:
>> I think, there is a difference between optional parameters and default parameter values. So, my suggestion would be
somethinglike this.
>> SELECT default_test(1,3, DEFAULT); -- match function number 1
>>
>> SELECT default_test(1,3); -- match the function number 2
>>
>> SELECT default_test(1); -- ERROR
>> Regards
> This would break at least 4 major applications which I personally have
> worked on, and the benefit to users is unclear at best.
>
> One of the main reasons to *have* default parameters is to allow adding
> new parameters to existing functions without breaking old application
> code. So, -1 from me.
>
me too.
The OP's statement that there is a difference between default params and
optional params doesn't compute. The only way params are optional is
that they have a default. Treating these as somehow independent is a
nonsense.
Furthermore, if we dropped function 2, then
select default_test(1,3)
would be a call to function 1. Then, if we followed this proposal,
creating function 2 would magically steer that call to function 2
instead. Talk about a footgun, and possibly a security risk too.
cheers
andrew
2014-02-26 20:36 GMT+01:00 Andrew Dunstan <andrew@dunslane.net>:
me too.
On 02/26/2014 01:51 PM, Josh Berkus wrote:On 02/26/2014 10:15 AM, salah jubeh wrote:I think, there is a difference between optional parameters and default parameter values. So, my suggestion would be something like this.This would break at least 4 major applications which I personally have
SELECT default_test(1,3, DEFAULT); -- match function number 1
SELECT default_test(1,3); -- match the function number 2
SELECT default_test(1); -- ERROR
Regards
worked on, and the benefit to users is unclear at best.
One of the main reasons to *have* default parameters is to allow adding
new parameters to existing functions without breaking old application
code. So, -1 from me.
The OP's statement that there is a difference between default params and optional params doesn't compute. The only way params are optional is that they have a default. Treating these as somehow independent is a nonsense.
Furthermore, if we dropped function 2, then
select default_test(1,3)
would be a call to function 1. Then, if we followed this proposal, creating function 2 would magically steer that call to function 2 instead. Talk about a footgun, and possibly a security risk too.
more overloaded functions with similar type signature is just dangerous and bad practice.
We would to disallow it.
Regards
Pavel
Pavel
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello Josh,
>This would break at least 4 major applications which I personally have
I clearly see this issue, and in my opinion , this is the greatest challenge for this proposal. So, I will say -1 if I consider the re-factoring need to be done in old code. My main concern of this post is not to push this proposal,
>worked on, and the benefit to users is unclear at best
Simply, overloading functions with the same parameter types but different numbers might be tricky. In the example above it is obvious that this will generate not only garbage -which is number 2 function- , but also number 1 function is restricted in use.
>One of the main reasons to *have* default parameters is to allow adding
>new parameters to existing functions without breaking old application
>code. So, -1 from me.
>new parameters to existing functions without breaking old application
>code. So, -1 from me.
I think, this could be handled by using overloading.
I see the benefits of the way the default parameters are defined; but also, they are affecting overloading. May be, a warning message when creating a function like above would be nice.
Regards
On Wednesday, February 26, 2014 7:51 PM, Josh Berkus <josh@agliodbs.com> wrote:
On 02/26/2014 10:15 AM, salah jubeh wrote:
> I think, there is a difference between optional parameters and default parameter values. So, my suggestion would be something like this.
> SELECT default_test(1,3, DEFAULT); -- match function number 1
>
> SELECT default_test(1,3); -- match the function number 2
>
> SELECT default_test(1); -- ERROR
> Regards
This would break at least 4 major applications which I personally have
worked on, and the benefit to users is unclear at best.
One of the main reasons to *have* default parameters is to allow adding
new parameters to existing functions without breaking old application
code. So, -1 from me.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
> I think, there is a difference between optional parameters and default parameter values. So, my suggestion would be something like this.
> SELECT default_test(1,3, DEFAULT); -- match function number 1
>
> SELECT default_test(1,3); -- match the function number 2
>
> SELECT default_test(1); -- ERROR
> Regards
This would break at least 4 major applications which I personally have
worked on, and the benefit to users is unclear at best.
One of the main reasons to *have* default parameters is to allow adding
new parameters to existing functions without breaking old application
code. So, -1 from me.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com