From: | JanWieck(at)t-online(dot)de (Jan Wieck) |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, dyp(at)perchine(dot)com |
Subject: | Re: Problem with disabling triggers in pg_dump |
Date: | 2000-07-25 13:52:44 |
Message-ID: | 200007251352.PAA20574@hot.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner wrote:
>
> An interesting problem has been brought to my attention in pg_dump
> (V7.0.2+, I think).
>
> It uses the following code to disable triggers prior to a data load:
>
> UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" !~ '^pg_';
>
> which works fine if it is currently connected as a superuser, or as the
> datdba. However, if it is connected as anybody else, they will get the error:
>
> pg_class: Permission denied
>
> The obvious solution is to reconnect as the datdba before running the code.
The above was a rude hack. Introduced because of the lack of
time when we discovered the problem during 7.0 BETA cycle
(IIRC). The ovious "solution" is to fix it.
The clean solution would be to have something like
ALTER SESSION DISABLE/ENABLE TRIGGERS
A global variable (like those for other session settings)
would cause the trigger manager to suppress their invocation
at all.
The new utility has to check if either the user has ALTER ALL
TABLES privilege, or has ALTER TABLE privilege for any
existing user table where triggers are defined for.
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 #
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2000-07-25 14:09:03 | Re: New Privilege model purposal |
Previous Message | Philip Warner | 2000-07-25 13:30:17 | Problem with disabling triggers in pg_dump |