Re: Constraints & pg_dump

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Constraints & pg_dump
Дата
Msg-id 200403170912.59557.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: Constraints & pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Constraints & pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Index creation takes for ever
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Further thoughts about warning for costly FK checks