Re: [BUGS] BUG #5053: domain constraints still leak - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] BUG #5053: domain constraints still leak
Date
Msg-id 3625.1253023523@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #5053: domain constraints still leak  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Sam" == Sam Mason <sam@samason.me.uk> writes:
>  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.

Well, the LEFT JOIN case is exactly why I feel that domain not-null
constraints are inherently broken.  The only clean way around it is to
decree that the output of a left join is not of the domain type after
all, but of its base type.  Which seems to me to be one side effect of
the wording in 4.17.4, though they are extending it to *all* evaluation
contexts not only outer joins.

I haven't yet read the additional material you guys found ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: CommitFest 2009-09: Now In Progress
Next
From: Andrew Dunstan
Date:
Subject: Re: CommitFest 2009-09: Now In Progress