On 4 August 2011 18:57, Peter Eisentraut <peter_e@gmx.net> wrote:
> Have you considered just cataloging NOT NULL constraints as CHECK
> constraints and teaching the reverse parser to convert "x CHECK (x IS
> NOT NULL)" to "x NOT NULL". It seems to me that we're adding a whole
> lot of hoopla here that is essentially identical to the existing CHECK
> constraint support (it must be, per SQL standard), for no additional
> functionality.
>
With this approach, if the user explicitly wrote "CHECK (x IS NOT
NULL)" would it end up setting attnotnull? Presumably, since the
pg_constraint entry would be indistinguishable, it would be difficult
to do otherwise. From a performance standpoint that might be a good
thing, but it's going to be bad for compatibility.
What if they wrote "CHECK (NOT x IS NULL)", or "CHECK (x IS DISTINCT
FROM NULL)"? How many variants would it reverse parse?
What would this do to error messages when the constraint is violated?
I'm not convinced this simplifies things much; it just moves the
complexity elsewhere, and at the cost of losing compatibility with the
current behaviour.
Regards,
Dean