Re: strange IS NULL behaviour

On Tue, Sep  3, 2013 at 09:44:33PM -0500, Merlin Moncure wrote:
> It gets worse and worse.  The IS NULL operator is already pretty much
> special cased -- in just about all other case concerning rowtypes (for
> example coalesce) 'null containing rowtypes are *not* considered to be
> null as the container itself has a null bit independent of it's
> elements which is expressly contrary to the SQL standard.  This is
> tragic; postgres's way of doing it (except with IS NULL) makes an
> awful lot of sense to me but here we are.  I think before making any
> behavior changes at all, we need to ask ourselves:
> 
> 1. Are we willing to break compatibility in order to move to spec
> compliant behavior?
> 2. and if so, what mountains do we have to cross to get there?
> 
> Your proposed change (implementation details aside) seems ok in the
> sense that it doesn't seem to have a lot of obvious side effects but
> the elephant in the room is #1; if the answer is 'no', then I'd say
> the best course of action is to let things be.

Yes, these are the right questions.  If we leave things unchanged, can
we document the behavior we currently have?  What I _think_ we have now
is that IS NULL in queries checks two levels deep for nulls, but checks
only one level deep for PL/pgSQL and constraints.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +