Re: Summary: changes needed in function defaults behavior

2008/12/18 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2008/12/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> 2008/12/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>> 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 view, you don't store select foo(11), but
>>> you have to store select foo(11, default, default).
>>
>> Seems pretty ugly; keep in mind you'd be looking at that notation
>> constantly (in \d, EXPLAIN, etc), not just in dumps.
>>
>
> yes, it's not perfect - and I have to agree, prepared statements,
> views should by (and it is) problem. I didn't expect it. On second
> hand (practical view) most of functions with defaults or variadic will
> not be overloaded (it's not argument), so we could be more strict in
> checking.

some primitive idea - we could to disallow defaults params for views.

Pavel

>
> regards
> Pavel Stehule
>
>> I think the most conservative thing to do is to treat varying numbers of
>> defaults as ambiguous for now. We can relax that later without breaking
>> working code, but we couldn't go the other way if something else comes
>> up.
>>
>> regards, tom lane
>>
>