>>>>> "Sam" == Sam Mason <sam@samason.me.uk> writes:
>> But there's a kicker: in Subclause 6.12, <cast specification>, in the>> General Rules is:>> >> a) If the <cast
operand>specifies NULL, then the result of CS is>> the null value and no further General Rules of this Subclause>> are
applied.>>>> That "no further General Rules" clause implies (assuming it's not a>> blatant mistake in the spec) that
thisrule is therefore skipped in>> the case of nulls:
Sam> I think the NOT NULL constraint is a PG specific constraint, ISam> can't see how it's allowed in the spec.
That's a good point; it doesn't seem to be.
But the spec _does_ appear to allow CHECK(VALUE IS NOT NULL) as a
domain constraint (in general the spec defines NOT NULL constraints
this way), and the wording from 6.12 implies that that check is still
skipped in the case of NULLs (so that constraint would stop you
inserting a null into a table column (I think), but not from casting a
null value to the domain type).
Sam> The NOT NULL constraint feels wrong as well, what are theSam> semantics of:
Sam> CREATE DOMAIN d AS INTEGER NOT NULL;Sam> SELECT a.n AS aa, b.n AS bbSam> FROM (VALUES (CAST(1 AS d)),(2))
a(n)Sam> LEFT JOIN (VALUES (CAST(1 AS d))) b(n) ON a.n = b.n;
Sam> in the presence of it? I'm expecting aa and bb both to come outSam> as domain "d", but this shouldn't work with
whatyou're sayingSam> the current semantics should be.
I think that's just another example of Tom's initial comment about how
broken domain "not null" constraints are currently.
--
Andrew (irc:RhodiumToad)
