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
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 |