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