Re: Summary: changes needed in function defaults behavior

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.

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
>