Re: Dumping/restoring fails on inherited generated column
От | Tom Lane |
---|---|
Тема | Re: Dumping/restoring fails on inherited generated column |
Дата | |
Msg-id | 3169466.1594841366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Dumping/restoring fails on inherited generated column (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Dumping/restoring fails on inherited generated column
|
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> Right, there were a number of combinations that were not properly >> handled. The attached patch should fix them all. It's made against >> PG12 but also works on master. See contained commit message and >> documentation for details. > committed to master and PG12 So ... this did not actually fix the dump/restore problem. In fact, it's worse, because in HEAD I see two failures not one when doing the same test proposed at the start of this thread: 1. make installcheck 2. pg_dump -Fc regression >r.dump 3. createdb r2 4. pg_restore -d r2 r.dump pg_restore: while PROCESSING TOC: pg_restore: from TOC entry 6253; 2604 226187 DEFAULT gtest1_1 b postgres pg_restore: error: could not execute query: ERROR: column "b" of relation "gtest1_1" is a generated column Command was: ALTER TABLE ONLY public.gtest1_1 ALTER COLUMN b SET DEFAULT (a * 2); pg_restore: from TOC entry 6279; 2604 227276 DEFAULT gtest30_1 b postgres pg_restore: error: could not execute query: ERROR: cannot use column reference in DEFAULT expression Command was: ALTER TABLE ONLY public.gtest30_1 ALTER COLUMN b SET DEFAULT (a * 2); pg_restore: warning: errors ignored on restore: 2 regards, tom lane
В списке pgsql-hackers по дате отправления: