Re: Constraints & pg_dump - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Constraints & pg_dump
Date
Msg-id 200403170912.59557.josh@agliodbs.com
Whole thread Raw
In response to Re: Constraints & pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Constraints & pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 BerkusAglio Database SolutionsSan Francisco



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Index creation takes for ever
Next
From: Bruce Momjian
Date:
Subject: Re: Further thoughts about warning for costly FK checks