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