From: Peter Eisentraut <peter_e@gmx.net>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: cataloguing NOT NULL constraints
Date: Sat, 06 Aug 2011 03:01:25 +0300
Message-ID: <1312588885.24208.40.camel@vanquo.pezone.net> (raw)
In-Reply-To: <1312488608-sup-8244@alvh.no-ip.org>
References: <20110707213401.GA27098@alvh.no-ip.org>
<CAEZATCVX792JjZHrv+CdO87GmJ1uo01AH+OQbcymspEyjyhyaQ@mail.gmail.com>
<1311291819-sup-6206@alvh.no-ip.org>
<CA+TgmoaJbuai2wiWjYUMsawZQL57wOhP7Kg9q=kkVO8qc97MQQ@mail.gmail.com>
<1311367030-sup-9426@alvh.no-ip.org>
<CA+TgmobQSR7QHfvH8fQ7dvUabQMBdFc1=Ef7ceJL9qeOm8Y1iw@mail.gmail.com>
<CAEZATCW_GXNedWnkJ6Jv98-AxtiSNL44dq-jx566JBLiye-dkg@mail.gmail.com>
<CA+TgmoaT7Np=k39aH=D=dpRYKJ=gwXmRMA029BBs0jBs--fD6w@mail.gmail.com>
<1311985058-sup-952@alvh.no-ip.org>
<CAEZATCU5mSytH6Buxp2YJ_ExwNcmbrYG8TKXc3Wg-EHLO78cWQ@mail.gmail.com>
<1312342392-sup-7189@alvh.no-ip.org>
<1312480674.24208.8.camel@vanquo.pezone.net>
<1312488608-sup-8244@alvh.no-ip.org>
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
> > Have you considered just cataloging NOT NULL constraints as CHECK
> > constraints and teaching the reverse parser to convert "x CHECK (x IS
> > NOT NULL)" to "x NOT NULL".
>
> Hmm, no, I admit I haven't. The current approach was suggested very
> early in the history of this patch.
Well, the early patch thought this was a small problem. Now we know
it's a big problem, so it might be better to solve it terms of another
big problem that is already solved. :-)
> > It seems to me that we're adding a whole
> > lot of hoopla here that is essentially identical to the existing CHECK
> > constraint support (it must be, per SQL standard), for no additional
> > functionality.
>
> Yeah, perhaps you're right. The main reason they were considered
> separately is that we wanted to have them to be optimized via
> pg_attribute.attnotnull, but my patch does away with the need for that
> because it is maintained separately anyway.
Hmm, OK, but in any case you could have kept attnotnull and treated it
as a kind of optimization that indicates whether you can derive
not-nullability from existing CHECK constraints (which you can easily do
in enough cases).
> Before embarking on rewriting this patch from scratch, I would like to
> know what's your opinion (or the SQL standard's) on the fact that this
> patch separated the PRIMARY KEY from NOT NULL constraints, so that they
> don't act exactly alike (to wit, the not-nullness of a PK does not
> inherit while the one from a NOT NULL constraint does).
The SQL standard deals with inheritance in terms of composite types,
which don't have constraints, so that doesn't give any guidance.
That said, I think the substitutability property of object-oriented
systems, namely that you can use a child object in place of a parent
object, requires in principle that we inherit all constraints (by
default, at least). We don't inherit primary keys because of
implementation issues with indexes, but at some point in the future we
should fix that. So to some degree, inheriting the not-null property of
primary keys while not inheriting the rest of it is a bit wrong, but it
would appear to be a step in the right direction, and changing
established behavior seems a bit gratuitous to me.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter_e@gmx.net, alvherre@commandprompt.com, dean.a.rasheed@gmail.com, robertmhaas@gmail.com
Subject: Re: cataloguing NOT NULL constraints
In-Reply-To: <1312588885.24208.40.camel@vanquo.pezone.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox