Re: COALESCE and NULLIF semantics

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: COALESCE and NULLIF semantics
Дата
Msg-id 22373.1252688344@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: COALESCE and NULLIF semantics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: COALESCE and NULLIF semantics  (Sam Mason <sam@samason.me.uk>)
Re: COALESCE and NULLIF semantics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: COALESCE and NULLIF semantics  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.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.

As far as I can see, this entire discussion turns on the complaint that
IS NULL gives different results for plain NULL and ROW(NULL,NULL,...);
if that weren't true then we wouldn't be arguing about whether COALESCE
is wrong.  We really ought to be focusing on that and not making random
adjustments to the behavior of "unknown".

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?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: COALESCE and NULLIF semantics
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: RfD: more powerful "any" types