On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
> Consider
>
> create function foo(f1 int, f2 int = 42, f2 int = 43) ...
> create view v1 as select foo(11);
>
> In CVS HEAD this gives
>
> regression=# \d v1
> View "public.v1"
> Column | Type | Modifiers
> --------+---------+-----------
> foo | integer |
> View definition:
> SELECT foo(11, 42, 43) AS foo;
>
> which is an accurate representation of the truth: if you change the
> defaults for function foo, v1 will keep on calling it with the old
> default values.
Ooh. Ow.
> Does anyone think this is either unsurprising or desirable?
Not I!
> 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?
> 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.
> Treating the defaults as being inserted at parse time at least ensures
> that v1's call to foo still works.
That leads to mysterious action-at-a-distance bugs, though. Too weird.
> This at least needs documentation, I think.
>
> Comments?
Documentation at least, yes, but it'd be better, I think, if the
planner inserted the defaults.
Best,
David
