"David E. Wheeler" <david@kineticode.com> writes:
> On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
>> I'm not sure we can do much to fix it, though. It'd probably be
>> possible to have the rewriter or planner insert the default
>> expressions, instead of the parser; but that creates its own issues.
> 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.
>> Suppose I had v1 defined as above and then did
>>
>> create or replace function foo(f1 int, f2 int, f2 int = 43) ...
>>
>> ie, remove one or more default expressions. *This function definition
>> no longer matches the original call*. If we did plan-time insertion of
>> defaults we'd have little choice but to fail when v1 is executed,
>> because there'd be no principled way to insert a default for f2.
> 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.
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.
regards, tom lane