Re: Another issue in default-values patch: defaults expanded too soon
От | David E. Wheeler |
---|---|
Тема | Re: Another issue in default-values patch: defaults expanded too soon |
Дата | |
Msg-id | F84B8B42-925D-45E9-B11E-14AAC1C9462D@kineticode.com обсуждение исходный текст |
Ответ на | Re: Another issue in default-values patch: defaults expanded too soon (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Another issue in default-values patch: defaults expanded too soon
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: