Re: Constraint documentation
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Lætitia Avrot <laetitia.avrot@gmail.com>
Cc: peter.eisentraut@2ndquadrant.com, bpd0018@gmail.com, vik.fearing@2ndquadrant.com, coelho@cri.ensmp.fr, pgsql-hackers@lists.postgresql.org
Date: 2018-08-09T21:32:03Z
Lists: pgsql-hackers
On 2018-Aug-07, Lætitia Avrot wrote: > Hi Peter, > > I understand what you're pointing at and I agree that it could be a good > thing to be able to dump/restore a table without problem. > > My point was that check constraints weren't supposed to be used that way > theorically (or maybe i'm mistaken ?) so I thought maybe we should just > inform the user that this kind of use of a check constraint is a misuse of > that feature. Tom Lane pointed out in another thread that the SQL standard lists feature F673 "Reads SQL-data routine invocations in CHECK constraints" which permits CHECK constraints to examine tables, so saying "you're not supposed to do this", while correct from a Postgres perspective, would be short-sighted ISTM, because we will make ourselves liars as soon as we implement the feature. I agree that we should point this out in *some* way, just not sure how. Maybe something like "Postgres does not currently support CHECK constraints containing queries, therefore we recommend to avoid them." I would not mention pg_dump by name, just say dumps may not restore depending on phase of moon. (BTW I'm not sure of the term "other tables". You could have a query that references the same table ...) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Clarify that cross-row constraints are unsupported
- 36d442a25a1a 12.0 landed