Re: strange IS NULL behaviour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange IS NULL behaviour
Date: 2013-09-04 01:43:14
Message-ID: 12574.1378258994@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> NULL returns true, and any further nesting returns false.

AFAICS, the only good argument for breaking backwards compatibility here
is if you can convince people that the new behavior is more conformant to
the SQL spec. Where's the chapter and verse that argues for this
interpretation?

And I will say once more that a patch that affects only the behavior of
eval_const_expressions can be rejected on its face. That code has to be
kept in sync with the behavior of execQual.c, not just whacked around by
itself. And then there are the NOT NULL constraint cases to worry about.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-09-04 02:27:38 Re: strange IS NULL behaviour
Previous Message Bruce Momjian 2013-09-04 01:32:44 Re: strange IS NULL behaviour