Re: BUG #6701: IS NOT NULL doesn't work on complex composites

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Rikard Pavelic" <rikard(dot)pavelic(at)zg(dot)htnet(dot)hr>
Cc: <pgsql-bugs(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #6701: IS NOT NULL doesn't work on complex composites
Date: 2012-06-21 14:29:21
Message-ID: 4FE2E9710200002500048881@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Rikard Pavelic <rikard(dot)pavelic(at)zg(dot)htnet(dot)hr> wrote:

> The only inconsistent thing is check constraint, which behaves as
> NOT column IS NULL instead of column IS NOT NULL as docs says.

So currently a NOT NULL constraint on a column with a composite type
is equivalent to:

CHECK (NOT c IS NULL)

and the question is whether that is correct, or whether it should be
equivalent to:

CHECK (c IS NOT NULL)

> I even prefer that behavior.

I think I prefer current behavior, too; but I'm inclined to be
guided by the SQL spec if it is unambiguous about which is correct.
(I haven't checked yet -- does anyone already know without having to
dig through the spec?) Either way, it probably deserves some brief
mention in the docs. FWIW, a strict reading of the current
PostgreSQL docs ("The column is not allowed to contain null
values.") matches the current behavior, since the other way would
need to be stated as something like "The column can only contain
non-null values."

-Kevin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-06-21 15:22:10 Re: BUG #6701: IS NOT NULL doesn't work on complex composites
Previous Message Viswanatham Kiran Kumar 2012-06-21 12:56:36 Re: log_truncate_on_rotation=on is not truncating