On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
I haven't really thought through the consequences of this, but one
thing
we could consider doing to tamp down the damage is to prohibit
changing
the number of defaultable parameters of an existing function, ie treat
pronargdefaults as not allowed to change during CREATE OR REPLACE
FUNCTION. The point here would be to ensure that function replacement
couldn't change the parser's decisions about whether a function
matches
a call or not; which is the case in existing releases, but has been
falsified by this patch.
If that's acceptable, then we could insert default expressions at plan
time with confidence that no defaults we need have disappeared under
us.
Wouldn't you still have the problem if you still allow the default
values to be changed? And I would hope that they could be changed!
There's another slightly annoying issue here, which is that in at
least
some cases, inserting defaults at plan time would require an
additional
traversal of the parsetree. This isn't a huge deal probably, but it
would result in some performance loss in long-but-simple queries.
Yes, and it avoids the principal of least surprise.
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
