Re: BUG #15316: pg_restore failes to load data that is constrainted by a functional check constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lalbin(at)scharp(dot)org
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15316: pg_restore failes to load data that is constrainted by a functional check constraints
Date: 2018-08-08 02:53:49
Message-ID: 13061.1533696829@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> I have found an edge case where pg_dump and pg_restore fails to restore
> databases with check constraints that points to data in another table that
> is restored after the table containing the check constraint.

This is an unsupported case.[1] In general, table CHECK constraints are
only allowed to concern themselves with the data in the particular row
that they're checking. While we can't actually stop you from cheating by
hiding the subquery in a function, we're not going to consider it a bug
that such a setup doesn't work reliably.

I'd suggest rethinking your data representation so that you can make the
tables' relationship into a regular foreign key constraint. Those, the
system understands well enough to maintain in a dump/reload context.

regards, tom lane

[1] Specifically, we disclaim support for SQL feature F671, "Subqueries
in CHECK constraints".

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-08-08 06:53:13 BUG #15317: Sort order error
Previous Message Peter Geoghegan 2018-08-08 01:06:59 Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0