From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "liam(at)morland(dot)ca" <liam(at)morland(dot)ca>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #18151: pg_upgradecluster fails when column default refers to column |
Date: | 2023-10-09 15:03:37 |
Message-ID: | 143483.1696863817@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sunday, October 8, 2023, PG Bug reporting form <noreply(at)postgresql(dot)org>
> wrote:
>> The reason is the the default value for column "event_id" of table "event"
>> is "event_id_nextval()". That function is:
>> SELECT COALESCE(MAX(event_id) + 1, 1) FROM event;
> You are expressly forbidden to have the default value expression of a
> column reference a subquery. You must use a trigger.
Well, you're not allowed to do it directly:
regression=# create table foo (f1 int default ((select max(f1) from foo)));
ERROR: cannot use subquery in DEFAULT expression
LINE 1: create table foo (f1 int default ((select max(f1) from foo))...
^
but that's just a minor implementation restriction. Doing it through
a function is fine. (Whether it's a good idea is another question.)
Unlike, say, CHECK constraints, there's not any expectation that
a default expression be immutable or avoid dependence on database
state --- if there was, "default nextval(...)" would be problematic.
In any case, dump/restore ought not fail like this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Liam Morland | 2023-10-09 16:13:05 | Re: BUG #18151: pg_upgradecluster fails when column default refers to column |
Previous Message | David G. Johnston | 2023-10-09 14:31:32 | Re: BUG #18151: pg_upgradecluster fails when column default refers to column |