From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Order of enforcement of CHECK constraints? |
Date: | 2015-03-23 14:16:36 |
Message-ID: | 31519.1427120196@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> I might be only one objecting here but ...
> On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 nothing else, so as not to have regression-test failures.
> If it really
> matters, we should probably report all the failing constraints.
That wouldn't in itself make the output deterministic (you'd still have to
sort); and in any case that's not going to happen because it would require
running each CHECK constraint in its own subtransaction. Catching errors
that way is *expensive*. And there's been zero field demand for such a
behavior, so I don't see us adding cycles for something no one's asked
for. Sorting the check constraints during relcache load, on the other
hand, is a negligible burden compared to the cost of reading
pg_constraint.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-03-23 14:18:19 | recovery_min_delay casting problems lead to busy looping |
Previous Message | Tom Lane | 2015-03-23 14:07:12 | Re: Table-level log_autovacuum_min_duration |