From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Another issue in default-values patch: defaults expanded too soon |
Date: | 2008-12-16 21:52:19 |
Message-ID: | F84B8B42-925D-45E9-B11E-14AAC1C9462D@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
> I haven't really thought through the consequences of this, but one
> thing
> we could consider doing to tamp down the damage is to prohibit
> changing
> the number of defaultable parameters of an existing function, ie treat
> pronargdefaults as not allowed to change during CREATE OR REPLACE
> FUNCTION. The point here would be to ensure that function replacement
> couldn't change the parser's decisions about whether a function
> matches
> a call or not; which is the case in existing releases, but has been
> falsified by this patch.
>
> If that's acceptable, then we could insert default expressions at plan
> time with confidence that no defaults we need have disappeared under
> us.
Wouldn't you still have the problem if you still allow the default
values to be changed? And I would hope that they could be changed!
> There's another slightly annoying issue here, which is that in at
> least
> some cases, inserting defaults at plan time would require an
> additional
> traversal of the parsetree. This isn't a huge deal probably, but it
> would result in some performance loss in long-but-simple queries.
Yes, and it avoids the principal of least surprise.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-16 21:55:37 | Re: Another issue in default-values patch: defaults expanded too soon |
Previous Message | Andrew Dunstan | 2008-12-16 21:43:27 | Re: Elide null updates |