| From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
|---|---|
| To: | fredrik(dot)widlert(at)digpro(dot)se, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Subject: | Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1 |
| Date: | 2019-01-07 13:28:25 |
| Message-ID: | CA+q6zcUHseOR7YGhoTn8Df_HBGUP4jfgmWuCB2vixhtU0=7phQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On Mon, Jan 7, 2019 at 1:33 PM PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>
> Is this a bug or pehaps an intended change? We tried googling but
> didn't find anything which seemed relevant.
Well, I guess it was introduced here [1] for fast ALTER TABLE ADD COLUMN
feature:
The default expression is evaluated at the time of the ALTER TABLE and the
result stored in a new column (attmissingval) in pg_attribute
Although I wonder if this case with current_setting was taken into account.
Probably it doesn't make sense to use fast alter table if a table is empty.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | a Marath | 2019-01-07 14:18:49 | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |
| Previous Message | Bartosz Polnik | 2019-01-07 12:56:09 | Re: BUG #15577: Query returns different results when executed multiple times |