Re: BUG #18151: pg_upgradecluster fails when column default refers to column
От | Tom Lane |
---|---|
Тема | Re: BUG #18151: pg_upgradecluster fails when column default refers to column |
Дата | |
Msg-id | 143483.1696863817@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18151: pg_upgradecluster fails when column default refers to column ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-bugs |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Sunday, October 8, 2023, PG Bug reporting form <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: