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.
Does anyone think this is either unsurprising or desirable?
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. 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.
Treating the defaults as being inserted at parse time at least ensures
that v1's call to foo still works.
This at least needs documentation, I think.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
