Re: Disable and enable of table and column constraints

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Michael Gould" <mgould(at)intermodalsoftwaresolutions(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disable and enable of table and column constraints
Date: 2009-09-09 14:23:29
Message-ID: 4AA77411020000250002ABB8@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> Both DB2 and Oracle have an ENFORCE setting for constraints, and a
> MySQL blog hinted some time ago that it might be in SQL 201x.

If I remember correctly, Sybase never checks the existing data when
you add a constraint of any type (except for a unique constraint or
primary key).

That has occasionally been useful to me when a business rule has been
identified which we want to enforce in an existing database, but there
hasn't yet been enforcement of that rule. You can "plug the leak"
first, then list the legacy problems and get those on a list for
cleanup. If you insist that all preexisting bad data must be cleaned
up before you can prevent more bad data from going in, you might never
*get* clean because of a steady dribble of additional bad data while
you are attempting cleanup.

(Well, OK, you could always enforce the rule at some other layer and
hope to get enough traction to correct the problems, but it is nice to
have help from the DBMS in this regard, without having to code
triggers to get there.)

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-09 14:25:34 Re: COALESCE and NULLIF semantics
Previous Message Alvaro Herrera 2009-09-09 14:20:07 Re: More robust pg_hba.conf parsing/error logging