From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Piotr S <stegiszn(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: pg_dump and pg_restore on inherited tables problem |
Date: | 2017-09-04 15:24:39 |
Message-ID: | 31331.1504538679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Piotr S <stegiszn(at)gmail(dot)com> writes:
> Hello, i think there is a problem with some specify situation when source
> database was set different default value between main and inherited table.
The problem here is that your child table doesn't have a not-null
constraint on the inh_level column, while the parent does. That's
a logically inconsistent situation, and it's not really pg_dump's
fault that it fails to reproduce it exactly.
We've fixed that problem in v10: now, the child table inherits the
not-null constraint when you do the ALTER ADD PRIMARY KEY. So your setup
script fails to insert the inconsistent data:
d1=# INSERT INTO test_otw(id, description) VALUES (1, 'some test row');
ERROR: null value in column "inh_level" violates not-null constraint
DETAIL: Failing row contains (1, null, some test row).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-09-04 23:06:16 | Re: pg_dump and pg_restore on inherited tables problem |
Previous Message | Piotr S | 2017-09-04 09:00:42 | pg_dump and pg_restore on inherited tables problem |