Re: Constraints & pg_dump

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Constraints & pg_dump
Date: 2004-03-17 17:12:59
Message-ID: 200403170912.59557.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> AFAIR, whether a constraint is syntactically attached to a column or is
> "loose" in the table definition is not supposed to have any semantic
> consequences, but I might be wrong about that too.

Well, a table-level CHECK constraint can attach to more than one column, so in
that way *is* different, regardless of whatever else the spec says about it.
For example,

table a (
col1 INT,
col2 INT,
CONSTRAINT less_than CHECK (col1 < col2)
);

The fact that the constraint is implemented as a function shouldn't make a
difference for us as long as all of the columns are named:

table users (
username text,
active boolean,
CONSTRAINT username_is_unique CHECK cf_user_unique(username, active)
);

in this case, the constraint should be triggered whenever either of the named
columns is updated. BTW, the above is basically Bricolage's problem ... they
want only active user names to be unique.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-03-17 17:15:41 Re: Further thoughts about warning for costly FK checks
Previous Message Tom Lane 2004-03-17 17:03:35 Re: Constraints & pg_dump