Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: fredrik(dot)widlert(at)digpro(dot)se, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1
Date: 2019-01-07 21:22:31
Message-ID: 80c8c7e4-8756-d206-bdd4-c1e69e4f9d4a@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)dunslane(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bartosz Polnik 2019-01-07 21:39:17 Re: BUG #15577: Query returns different results when executed multiple times
Previous Message Andres Freund 2019-01-07 21:11:20 Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1