Re: Heading to final release

Rod Taylor wrote:
>> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
>> >> > constraints/triggers, not settable from postgresql.conf?
>> >>
>> >> Is that one really necessary for 7.4 now that adding foreign keys is
>> >> apparently much faster?
>
>> If you reconfigure your systems to force fsck on every boot, cleanly
>> unmounted or not, you can vote against. Otherwise you are basically for
>> this option.
>
> I vote to disable the checks for pg_restore if the dumpfile has a check
> added to ensure it's the same file that was dumped (an MD5 in the
> header) and it is a full database restore.
>
> Individual table restores should require the check.

I don't like it.

Rod, this is not meant personal, more some sort of general sigh:

Why do people wait until the EMT cannot give the life-saving infusion
any more before they realize that "invincible" isn't that great at all?

Some dumb-user/fat-finger/ooops protection is surely welcome, but there
is a limit. A system console has to be behind a locked door instead of
the single-user boot being root-password protected. As soon as people
succeed in "chmod 0000 /" and it honor's that for root even if the disk
is mounted on a different system, they will see that there is something
missing - ooops, too late?

I am talking about some special super-user flag. Something that is
available for the user who has usecatupd anyway and because of that he
can do a

DELETE FROM pg_class WHERE relname = 'pg_class';

What good is it to deny "that" user to import any dump without foreign
key check? Any attempt to do so only makes it "more inconvenient". But
you surely don't prevent anything by doing so.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #