On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
>> Would the same thing happen for a prepared statement that calls the
>> function? Or another function?
>
> Prepared statements and functions don't have such a problem, because
> they don't have a long-lived parsetree representation. If you change
> the defaults attached to an existing function, that will result in an
> invalidation on all plans referencing the function (thanks to some
> changes that went in a commitfest or two back), and things should
> pretty much "just work". A view or rule is a bigger problem because
> it will have a hard binding to a particular function OID.
Well, that's good, except that the behavior then becomes inconsistent
in rules and views vs. everything else. I understand the underlying
reasons for this (thanks to your reply here), but those not familiar
with the architecture will find it mystifying. Documentation, at the
very least, is certainly in order.
>> That seems like it'd be the reasonable thing to do.
>
> 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.
> In some ways this is analogous to the problem of "when do you expand *
> in a SELECT list?". The SQL spec is clear that it's expanded at
> CREATE
> VIEW time; but there are certainly lots of cases where people wish it
> didn't work like that.
Yeah, function default values aren't specified by the spec, are they?
Best,
David