From: Tom Lane <tgl@sss.pgh.pa.us>
To: JED WALKER <jedwa@comcast.net>
cc: "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>,
        "Jed@ICD" <jed.walker@icd-tech.com>
Subject: Re: v12.4 pg_dump .sql fails to load data via psql
In-reply-to: <375102856.69594.1633991178400@connect.xfinity.com>
References: <375102856.69594.1633991178400@connect.xfinity.com>
Comments: In-reply-to JED WALKER <jedwa@comcast.net>
	message dated "Mon, 11 Oct 2021 16:26:17 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <526203.1633992925.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 11 Oct 2021 18:55:25 -0400
Message-ID: <526204.1633992925@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/526204.1633992925%40sss.pgh.pa.us>
Precedence: bulk

JED WALKER <jedwa@comcast.net> writes:
> PostgreSQL v12.4 pg_dumpall output fails to load via "psql -f" load to e=
mpty instance/server.
> This occurs using check constraints that reference a function using data=
 in a table that is loaded later.

That's never worked reliably, neither in v12 nor any other version.
The function is a "black box", so the fact that it creates an ordering
constraint isn't apparent to pg_dump.

Note that our documentation specifically disclaims correct enforcement
of CHECK constraints that reference any mutable data other than the row
being checked (see NOTEs at [1]).  Even if the particular scenario you
describe here happened to work, there are many other cases where such a
constraint could become violated after it was initially checked --- and
Postgres wouldn't notice.  Nor do we have any interest in making it
notice.

			regards, tom lane

[1] https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONST=
RAINTS-CHECK-CONSTRAINTS