On Wed, Oct 10, 2018 at 4:26 AM Amit Langote
<Langote_Amit_f8@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
