DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=PecNZD1ZhmrLUXGLyhvV/15DCN5M6/kdkgxiuK/oJChXSmK3c2GBmuuWyPwFEjoCaNr3SJYK3rJM16f6qeNQmfHHLMfqF2C06hnw981sh+YLRJoisK3dgq7aa8FGYQr1Iq5xFnybQz2blbiq4h6b1TQPyWnzCfQMnkGCbz+wCAQ=;
References: <51A37A72.5000203@joh.to> <51A89BAE.6000704@joh.to>
Message-ID: <1370173658.22143.YahooMailNeo@web162902.mail.bf1.yahoo.com>
Date: Sun, 2 Jun 2013 04:47:38 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: ALTER TABLE lock level
To: Marko Tiikkaja <marko@joh.to>,
	"pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
In-Reply-To: <51A89BAE.6000704@joh.to>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Marko Tiikkaja <marko@joh.to> wrote:
> On 5/27/13 5:23 PM, I wrote:
>> Today I got (unfortunately) reminded that this statement, in
>> sql-altertable.html under VALIDATE CONSTRAINT, is not true anymore:
>>
>> The value of separating validation from initial creation of the
>> constraint is that validation requires a lesser lock on the table than
>> constraint creation does.
>
> Since nobody seems to want to pick this up, I'm going to suggest the
> following wording:
>
>=A0=A0=A0=A0 The value of separating validation from initial creation of t=
he
>=A0=A0=A0=A0 constraint is that you can immediately start enforcing the
>=A0=A0=A0=A0 constraint on all future rows, but delay the validation of
>=A0=A0=A0=A0 pre-existing data until your database is not under heavy load.

That's good as far as it goes, but there's another major reason for
wanting the capability.=A0 There are cases where, due to dirty
converted data or late recognition of the need for a constraint
there is existing data which violates the constraint.=A0 Being able
to add a constraint to protect against creating additional bad data
before all the existing problems are cleaned up can be valuable.

I know of cases where the old rows which violate the constraint may
persist for decades.=A0 In a court setting they may care a lot that
data on a new and active court case is forced to be correct when
entered, but may not feel that it is worth the cost (or in some
cases even possible) to determine correct values for cases which
are 10 or 20 (or 120) years old.=A0 These cases can't be deleted due
to records retention laws or relevant court rules, and for a DBA to
update them with bogus values to make them comply with the
constraint would be not only potentially more misleading than
leaving them alone, but would be a felony.

> But I'm not going to object to simply removing the entire sentence.

I don't know -- it seems like the reasons for the feature are
non-obvious enough that such a note is useful.

--=20
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs