Re: [HACKERS] Function sugnature with default parameter
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
Re: [HACKERS] Function sugnature with default parameter
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
Re: [HACKERS] Function sugnature with default parameter
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Function sugnature with default parameter
2014-02-26 20:36 GMT+01:00 Andrew Dunstan and...@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 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. more overloaded functions with similar type signature is just dangerous and bad practice. We would to disallow it. Regards 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
Re: [HACKERS] Function sugnature with default parameter
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 j...@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
