Re: strange IS NULL behaviour

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-07 03:07:04
Message-ID: 20130907030704.GB11757@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> >> Another possible fix would be to avoid the IS NULL value optimizer
> >> expansion if a ROW construct is inside a ROW(). I have attached a patch
> >> that does this for review.
>
> > Having received no replies, do people perfer this version of the patch
> > that just punts nested ROW IS NULL testing to execQual.c?
>
> For some reason I read your previous message as saying you were willing to
> wait for considered reviews this time. If not, I'll just write a blanket
> -1 for any version of this patch.

Are you saying people will comment later? I wasn't clear that was the
plan. I can certainly wait.

> I don't think you've shown that this is more spec-compliant than what
> we had before, nor that you've made all the relevant code (execQual,
> eval_const_expressions, column NOT NULL constraints, plpgsql variable
> NOT NULL constraints, maybe other places) mutually consistent.

I believe all the other places (execQual, plpgsql variables) all treat
embedded row in rows as non-null, but I don't even know how to test all
the place. Can someone do that?

> I'm not a fan of incremental improvements in application-visible
> semantics: if we change this repeatedly over several releases, that's an
> application author's worst nightmare, because he'll have to try to work
> with multiple different behaviors. We need to change this *once* and get
> it right. You haven't proven that this is now right where it wasn't
> before, and the patch is certainly not so obviously right that it should
> go in without considered review.

Yes, we have to be sure to get this right. However, I am not able to
test all the places you have mentioned, so unless someone else finds
this important enough to work on, I will just document it as a TODO and
close it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-09-07 03:19:37 Re: [RFC] Extend namespace of valid guc names
Previous Message Tom Lane 2013-09-07 03:00:24 Re: strange IS NULL behaviour