Re: Dumping/restoring fails on inherited generated column - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dumping/restoring fails on inherited generated column
Date
Msg-id 3169466.1594841366@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dumping/restoring fails on inherited generated column  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Dumping/restoring fails on inherited generated column  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Floris Van Nee
Date:
Subject: Generic Index Skip Scan