From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | JED WALKER <jedwa(at)comcast(dot)net> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, "Jed(at)ICD" <jed(dot)walker(at)icd-tech(dot)com> |
Subject: | Re: v12.4 pg_dump .sql fails to load data via psql |
Date: | 2021-10-11 22:55:25 |
Message-ID: | 526204.1633992925@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
JED WALKER <jedwa(at)comcast(dot)net> writes:
> PostgreSQL v12.4 pg_dumpall output fails to load via "psql -f" load to empty 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-CONSTRAINTS-CHECK-CONSTRAINTS
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-10-12 00:37:51 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Previous Message | David G. Johnston | 2021-10-11 22:48:13 | Re: v12.4 pg_dump .sql fails to load data via psql |