I might be only one objecting here but ... On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane <t...@sss.pgh.pa.us> 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. > Why is it important to report in deterministic manner? If it really matters, we should probably report all the failing constraints. A comparable example would be compiler throwing errors. > > 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? > Downthread, parallels are being drawn with triggers. The order in which triggers are fired matters since the triggers can affect each other's results but constraint don't do that. Do they? So, why should we waste some cycles in sorting the constraints? > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
