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