Re: BUG #15579: Adding a column with default from configurationparameter fails on 11.1
От | Andrew Dunstan |
---|---|
Тема | Re: BUG #15579: Adding a column with default from configurationparameter fails on 11.1 |
Дата | |
Msg-id | 80c8c7e4-8756-d206-bdd4-c1e69e4f9d4a@dunslane.net обсуждение исходный текст |
Ответ на | Re: BUG #15579: Adding a column with default from configurationparameter fails on 11.1 (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On 1/7/19 4:11 PM, Andres Freund wrote: > On 2019-01-07 16:01:43 -0500, Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> Stable expressions are quite ok for fast defaults. The expression is >>> evaluated once when the ALTER TABLE is done and the result (not the >>> expression) is stored in the catalog. The reason we check for volatile >>> expressions is precisely because we don't want all the existing rows to >>> get a single value in that case. This was discussed during the Postgres >>> 11 development cycle. >> Hmm. >> >> The issue here is that if the table is empty, the old behavior evaluated >> the expression zero times during ALTER TABLE. Now we evaluate it once, >> and if that throws an error, that's a user-visible behavior change. >> >> Perhaps it's okay to decide that that's an acceptable behavioral change, >> but it makes this feature less transparent than it was supposed to be. That's true. But only slightly less transparent, I'd suggest :-) > It doesn't seem too hard to scan far enough to see whether there's a > single non-dead row. So we could fix this, if we wanted. > > But I'm disinclined to think that it's worth doing so - and there could > be drawbacks, e.gg tables that are all-dead. Given the IMO quite minor > behaviour change, I'm thus disinclined to "fix" this.. > agreed. It might be worth a doc note? cheers andrew
В списке pgsql-bugs по дате отправления: