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';
-- 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)
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
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM29dd0061cda8beb988ab23c71187f017e17b49b54372f8fda2840f439a1b82745305f20d2e3fe05625dfa41fec177131@asav-3.01.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 something like this.
SELECT default_test(1,3, DEFAULT); -- match function number 1SELECT default_test(1,3); -- match the function number 2
SELECT default_test(1); -- ERROR
RegardsThis 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-02-26 20:36 GMT+01:00 Andrew Dunstan <andrew@dunslane.net>:
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.
SELECT default_test(1,3, DEFAULT); -- match function number 1SELECT default_test(1,3); -- match the function number 2
SELECT default_test(1); -- ERROR
RegardsThis 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.
more overloaded functions with similar type signature is just dangerous and
bad practice.
We would to disallow it.
Regards
Pavel
Show quoted text
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.
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