Re: COALESCE and NULLIF semantics

On Fri, Sep 11, 2009 at 12:59:04PM -0400, Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> > I'm only proposing parse-time changes for conditional
> > expressions -- the CASE predicate and its abbreviations.
>
> No, you are not; you are proposing run-time changes, specifically the
> need to coerce unknown to something else long after the point where
> the unknown is just a literal constant.

One thing I've just realized these discussions have pointed out is
that PG isn't doing the correct thing all the time with types. When
is it ever valid to see an "unknown" after type checking? AFAICT, it
shouldn't ever appear and hence doing:

CREATE VIEW v AS SELECT 'foo';

Should be doing the normal default to TEXT type. Is that right? or does
"unknown" have more meaning besides just being something that needs to
be fixed up during type checking.

> I've been wondering whether it would be sensible to make the
> composite-datum constructors check for all-null fields and generate
> a plain NULL if so. If so then ROW(NULL,NULL) would be
> indistinguishable from NULL and the semantic gripes seem to largely
> go away. It would be a problem for anyone who actually wanted to
> distinguish those two cases, but how much do we care?

I'd prefer these semantics; it would make it do "the right thing" in
more cases than now.

--
Sam http://samason.me.uk/