Re: Another issue in default-values patch: defaults expanded too soon

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