Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> So currently a NOT NULL constraint on a column with a composite
>> type is equivalent to:
>> CHECK (NOT c IS NULL)
> I don't believe this statement is accurate. What's really
> happening is that a column-not-null constraint is a
> datatype-independent check for whether the datum per se is null or
I stand corrected.
> Somebody who really cares about having the SQL-spec definition can
> write a CHECK constraint as suggested above, and then he'll get
> the composite-type-aware behavior, so it's not like there's no way
> to get that.
> BTW, the same inconsistency exists for function-argument
> strictness checks: those will consider a heaptuple-of-all-nulls to
> be something you can call a strict function with. I think
> changing this would be a pretty bad idea, not only on modularity
> and performance grounds but because it'd likely break existing
> applications that expect the current behavior.
Maybe a comment or two in the docs covers it?
> regression=# select null::int8_tbl is distinct from
> (1 row)
> It's not clear to me whether the SQL standard rules on what should
> happen in this case, or whether we should listen to it if it does
> say that these values are not distinct. They certainly *look*
I do sympathize with the point of view that a row value about which
absolutely no applicable facts are known is a lot like not knowing
what row you have, but they do seem distinct when you look at the
> (Oh, and dare I mention arrays of nulls?)
Hey, look! An elephant!
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2012-06-21 18:23:52|
|Subject: Re: BUG #6701: IS NOT NULL doesn't work on complex composites|
|Previous:||From: Feng Gao||Date: 2012-06-21 17:39:43|
|Subject: Bug #6201 status.|