From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | fredrik(dot)widlert(at)digpro(dot)se |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1 |
Date: | 2019-01-07 14:57:59 |
Message-ID: | 3336.1546873079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> ... creating the table first and then adding the column does not
> work on 11.1. It used to work at least from version 9.3 to 10.
> create table t (x int);
> alter table t add c varchar(50) default
> current_setting('public.some_setting');
> ERROR: unrecognized configuration parameter "public.some_setting"
I think this is a brown-paper-bag bug in the fast-column-default feature.
current_setting() is stable, and should certainly not be treated as a
fast default, but behold the test looks like this:
/* If the DEFAULT is volatile we cannot use a missing value */
if (colDef->missingMode && contain_volatile_functions((Node *) expr))
colDef->missingMode = false;
Of course, it should be insisting that the expression be immutable,
not just that it not be volatile.
- /* If the DEFAULT is volatile we cannot use a missing value */
- if (colDef->missingMode && contain_volatile_functions((Node *) expr))
+ /* missingMode can only be used for immutable defaults */
+ if (colDef->missingMode && contain_mutable_functions((Node *) expr))
colDef->missingMode = false;
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-01-07 17:36:13 | Re: BUG #15579: Adding a column with default from configuration parameter fails on 11.1 |
Previous Message | Alvaro Herrera | 2019-01-07 14:54:03 | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |