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