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
2014-02-26 20:36 GMT+01:00 Andrew Dunstan :
>
> 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
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 d
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 funct
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;
> $$
> LANG
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
