On 21/03/15 08:15, Tom Lane wrote:
My Salesforce colleagues noticed some tests flapping as a result of table
CHECK constraints not always being enforced in the same order; ie, if a
tuple insertion/update violates more than one CHECK constraint, it's not
deterministic which one is reported. This is evidently because
relcache.c's CheckConstraintFetch() just happily loads up the constraints
in whatever order it happens to find them in pg_constraint.
There's at least one regression test case where this can happen, so we've
been lucky so far that this hasn't caused buildfarm noise.
We could fix it by, say, having CheckConstraintFetch() sort the
constraints by name after loading them.
In principle the same problem could occur for domain CHECK constraints,
though the odds of multiple CHECKs failing are probably a lot lower.
Do people think this is worth fixing?
regards, tom lane
I think that this is a good idea, I would have implicitly assumed that
it was deterministic.
Additionally, people could then name CHECK constraints in a way to get
whatever order they wanted.
The documentation of CREATE TRIGGER says (reading Fabrizio's post
inspired me to look it up):
"If multiple triggers of the same kind are defined for the same event,
they will be fired in alphabetical order by name."
So I would have implicitly assumed the same for CHECK constraints, had I
recently read that.
So I think the current situation is a violation of POLA.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
