From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, 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:11:20 |
Message-ID: | 20190107211120.6dztmhvm3hmmee4z@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
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..
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-01-07 21:22:31 | Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1 |
Previous Message | Tom Lane | 2019-01-07 21:01:43 | Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1 |