From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Summary: changes needed in function defaults behavior |
Date: | 2008-12-17 23:56:24 |
Message-ID: | 13568.1229558184@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-12-18 00:09:02 | Re: Summary: changes needed in function defaults behavior |
Previous Message | Marko Kreen | 2008-12-17 23:49:47 | Re: Patch to eliminate duplicate b64 code from pgcrypto |