Re: Data integrity and sanity check

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: Data integrity and sanity check
Дата
Msg-id 0d0b01c1d800$6326eea0$8001a8c0@jester
обсуждение исходный текст
Ответ на Data integrity and sanity check  (Ferruccio Zamuner <nonsolosoft@diff.org>)
Ответы Re: Data integrity and sanity check  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Data integrity and sanity check  (Jan Wieck <janwieck@yahoo.com>)
Список pgsql-hackers
> 2) re-check any constraint inserted into the database

There should not be any if it was accepted, however if it's a new
constraint it doesn't get applied to data that already exists.  A dump
and restore will ignore these as well (with good reason).

I suppose the easiest way to find if data violates current constraints
(rather than the constraints applied during initial insertion) is to:

update table set column = column;

That should re-process any constraints.


Primary keys, or other index style constraints (UNIQUE for example)
are always guarenteed.  The only way that new constraints are added is
via alter table commands.

BTW.  There are good reasons sometimes for having data that violates
current constraints.  The top of a tree may have a static record with
a null parent.  The NOT NULL constraint added after this entry (via
alter table add constraint) should not affect the static record, so
unless you know your data quite well this type of tool wouldn't be
particularly useful anyway.

Normally I use triggers which are programmed to account for that, but
there are a few cases where the check constraint speed (rather than
the trigger) is useful and the assumption the initial record will
never be touched is good enough.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ferruccio Zamuner
Дата:
Сообщение: Data integrity and sanity check
Следующее
От: Greg Copeland
Дата:
Сообщение: Re: Posix AIO in new Red Hat Linux