Re: Summary: changes needed in function defaults behavior

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary: changes needed in function defaults behavior
Date: 2008-12-18 00:09:02
Message-ID: 162867790812171609u20d5f4b1h6b59ba07710cb582@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-12-18 00:11:16 Re: Summary: changes needed in function defaults behavior
Previous Message Tom Lane 2008-12-17 23:56:24 Re: Summary: changes needed in function defaults behavior