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