Re: Summary: changes needed in function defaults behavior - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Summary: changes needed in function defaults behavior
Date
Msg-id 162867790812171609u20d5f4b1h6b59ba07710cb582@mail.gmail.com
Whole thread Raw
In response to Re: Summary: changes needed in function defaults behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Summary: changes needed in function defaults behavior  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-hackers
2008/12/18 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/12/17 Tom Lane <tgl@sss.pgh.pa.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
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Summary: changes needed in function defaults behavior
Next
From: "Pavel Stehule"
Date:
Subject: Re: Summary: changes needed in function defaults behavior