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-07-04 20:29:20
Message-ID: 28090.1372969760@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:
> I developed the attached patch which properly recurses into ROW()
> records checking for NULLs; you can see it returns the right answer in
> all cases (and constant folds too):

My recollection of the previous discussion is that we didn't have
consensus on what the "right" behavior is, so I'm not sure you can just
assert that this patch is right. In any case this is only touching the
tip of the iceberg. If we intend that rows of nulls should be null,
then we have got issues with, for example, NOT NULL column constraint
checks, which don't have any such recursion built into them. I think
the same is true for plpgsql variable NOT NULL restrictions, and there
are probably some other places.

> The optimizer seems like the right place to fix this, per my patch.

No, it isn't, or at least it's far from the only place. If we're going
to change this, we would also want to change the behavior of tests on
RECORD values, which is something that would have to happen at runtime.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-07-04 21:06:05 Re: strange IS NULL behaviour
Previous Message Fabien COELHO 2013-07-04 19:06:10 Re: [PATCH] big test separation POC