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

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
>> I'm not too thrilled about it. One thing to consider is that with the
>> default gone, it might be that there is some other function that
>> matches
>> the textual call better than this one. But we can't really change the
>> view to reference that other function. So it's going to work
>> differently than the replan-from-source case, no matter what.

> Bleh.

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.

(It might be enough to not allow pronargdefaults to decrease. Not sure
about that though. It's certainly possible that adding a default could
make a call ambiguous when it was not before.)

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.

regards, tom lane