>>>>> "Sam" == Sam Mason <s...@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 this rule is therefore skipped in >> the case of nulls: Sam> I think the NOT NULL constraint is a PG specific constraint, I Sam> 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 the Sam> semantics of: Sam> CREATE DOMAIN d AS INTEGER NOT NULL; Sam> SELECT a.n AS aa, b.n AS bb Sam> 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 out Sam> as domain "d", but this shouldn't work with what you're saying Sam> 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
