Re: Another issue in default-values patch: defaults expanded too soon

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