Re: Review: Non-inheritable check constraints

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Nikhil Sontakke <nikkhils(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Non-inheritable check constraints
Date: 2011-12-23 15:27:32
Message-ID: CA+TgmobYkJscHA9UO6+fQKh=e_v9=9Yj-pzR9n9DSiFVevo-vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 22, 2011 at 10:54 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> I agree with Robert that this usage of ALTER TABLE ONLY is slightly
> different from other usages of the same command, but I disagree that
> this means that we need another command to do what we want to do here.
> IOW, I prefer to keep the syntax we have.

Another disadvantage of the current syntax becomes evident when you
look at the pg_dump output. If you pg_dump a regular constraint, the
constraint gets added as part of the table definition, and the rows
are all checked as they are inserted. If you pg_dump an ONLY
constraint, the constraint gets added after loading the data,
requiring an additional full-table scan to validate it.

>> > I am tempted to say we should revert this and rethink.  I don't
>> > believe we are only a small patch away from finding all the bugs here.
>>
>> Sure, if we all think that CREATE TABLE should support ONLY CONSTRAINT type
>> of syntax, then +1 for reverting this and a subsequent revised submission.
>
> I don't think this is a given ...  In fact, IMO if we're only two or
> three fixes away from having it all nice and consistent, I think
> reverting is not necessary.

Sure. It's the "if" part of that sentence that I'm not too sure about.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-23 15:32:29 Re: xlog location arithmetic
Previous Message Tom Lane 2011-12-23 15:18:21 Re: xlog location arithmetic