"David E. Wheeler" <da...@kineticode.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers