Tom Lane wrote:
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> I think we need someway of telling postgres to suppress a foreign key check.
>
> Well, the subtext argument here is "do we fix it by providing a way to
> suppress the check, or do we fix it by making the check fast enough to
> be tolerable?"
>
> I think the advantages of choice (b) are obvious --- it doesn't allow
> bogus data to be loaded accidentally, and it doesn't create a problem
> with loading existing 7.3 dump files that don't know how to suppress the
> check.
>
> If we find there is no way to do (b) acceptably well, then and only then
> would I want to consider (a).
I think I can accept it to be the choice of the DBA what to do. Pg_dump
has that kind of options already, one can choose between COPY and INSERT
for example. Why not adding the choice of dumping FKeys as ALTER TABLE
or CREATE CONSTRAINT TRIGGER?
The whole "original" idea (way back a few years ago) of doing it with
the CREATE CONSTRAINT TRIGGER command was, that your "backup" ought to
be consistent anyway. Finding out that your tape contains inconsistent
garbage _after_ your harddisk made that suspicious noise ... is a bit
late, isn't it?
That ALTER TABLE ... ADD CONSTRAINT needs to be improved, because at the
moment it is normally used we cannot make any assumptions about data
consistency, no question. But just because we have such a nice and
allways asked for ALTER TABLE command does not mean we have to force
every DBA of every well maintained and stable system to perform hourly
long nonsense-tests on known-to-be-good data.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #