On Mon, Sep 14, 2009 at 10:22:34AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > It seems like regardless of this discussion you oughtn't to be able to
> > store a NULL into that table column. But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
> extracts a column of type X from someplace, what it has is a valid value
> of type X.
Yup; the deeper problem seems to be that the table was created as:
create table test (a tstdom);
and not as:
create table test (a tstdom not null);
which is how you seem to be treating it.
> Depending on what we decide about the whole composite-null
> mess, maybe we will be forced to abandon that assumption ... but I'm
> sure not going to do so until my back is to the wall.
There seems to be a little space yet!
This whole issue seems only distantly related to the treatment of null
rows to me. I think PG has got its semantics confused along the way
somewhere and things need tweaking. The only way I can get it all to
work nicely in my head is if ROW(NULL) evaluates to a NULL value (and
not a row containing a NULL value, as it does at the moment) and the
NULL/NOT NULL constraint on the CREATE DOMAIN is used somehow for the
nullness constraint of any columns using this domain. It's the second
part that seems to be more critical, but there are various ways of
interpreting the meaning.
I'm tempted to say that the nullness specified in the domain puts a
bound on the amount of nullness available--i.e. it would be impossible
to create a nullable column from a domain that specified NOT NULL. The
reason it's only a "limit" is that it seems useful to be able to say
that a normally nullable domain can't be null for this column in this
table. Not sure if this is what people want though.
You then get into fun cases like:
create domain tstdom as integer;
create domain tstdom2 as tstdom;
--
Sam http://samason.me.uk/
