I would agree with making it stricter. It would force people to do less
stupid things.
Our main use case for default parameter will be getting rid of all the old
versions of functions with shorter parameter lists by just creating new
versions of old functions with additional default parameters.
We
Tom Lane wrote:
> So to summarize what I think we agreed to yesterday:
>
> * CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
> value of an existing function (ie, you can add more defaults but not
> remove any). This ensures a function that matched a given call before
> will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 18 déc. 08 à 00:56, Tom Lane a écrit :
"Pavel Stehule" writes:
do you remember on request for using "default" keyword in funccall?
This should be solution. In view, you don't store select foo(11), but
you have to store select foo(11, defau
2008/12/18 Pavel Stehule :
> 2008/12/18 Tom Lane :
>> "Pavel Stehule" writes:
>>> 2008/12/17 Tom Lane :
Experimenting with the revised code, I found a curious case that might
be worth worrying about. Consider the example that started all this:
>>
>>> do you remember on request for using
2008/12/18 Tom Lane :
> "Pavel Stehule" writes:
>> 2008/12/17 Tom Lane :
>>> Experimenting with the revised code, I found a curious case that might
>>> be worth worrying about. Consider the example that started all this:
>
>> do you remember on request for using "default" keyword in funccall?
>>
"Pavel Stehule" writes:
> 2008/12/17 Tom Lane :
>> Experimenting with the revised code, I found a curious case that might
>> be worth worrying about. Consider the example that started all this:
> do you remember on request for using "default" keyword in funccall?
> This should be solution. In vi
2008/12/17 Tom Lane :
> I wrote:
>> * Two functions that could match a given call after adding defaults
>> are considered ambiguous only if they would add the same number of
>> defaults; otherwise we prefer the one with fewer parameters. This
>> generalizes the rule that an exact match (no default
I wrote:
> * Two functions that could match a given call after adding defaults
> are considered ambiguous only if they would add the same number of
> defaults; otherwise we prefer the one with fewer parameters. This
> generalizes the rule that an exact match (no defaults) is preferred
> over one t
2008/12/17 Tom Lane :
> So to summarize what I think we agreed to yesterday:
>
> * CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
> value of an existing function (ie, you can add more defaults but not
> remove any). This ensures a function that matched a given call before
>
So to summarize what I think we agreed to yesterday:
* CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
value of an existing function (ie, you can add more defaults but not
remove any). This ensures a function that matched a given call before
will continue to do so.
* CREAT
10 matches
Mail list logo
