Re: Order of enforcement of CHECK constraints?
От | Tom Lane |
---|---|
Тема | Re: Order of enforcement of CHECK constraints? |
Дата | |
Msg-id | 31519.1427120196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Order of enforcement of CHECK constraints? (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: Order of enforcement of CHECK constraints?
|
Список | pgsql-hackers |
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes: > I might be only one objecting here but ... > On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane <tgl@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 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
В списке pgsql-hackers по дате отправления: