On Wed, Oct 10, 2018 at 4:26 AM Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On the other hand, the syntax of CHECK constraints allows a fairly wide > range of expressions to be specified, with expressions/values of arbitrary > types and operators with arbitrary semantics (not limited to > btree/ordering semantics, for example). It won't be a good enough > solution if it can provide the error for only a certain subset of > user-specified expressions, IMHO.
It's impossible to solve that problem in general -- solving it for only a certain subset of user expressions is the best we can ever do. If you found a fully general solution, you would have solved the halting problem, which has been proved to be impossible. Now, I think there is a reasonable argument that it would still be nice to give an ERROR diagnostic in the cases we can detect, but I do not agree with that argument, for all of the reasons stated here: the development resources are better spent elsewhere, somebody might be creating such a contradictory constraint deliberately for whatever purpose, it might annoy or confuse users to get the error in only some cases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
