From: | Joseph Tate <jtate(at)dragonstrider(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_restore problems and suggested resolution |
Date: | 2004-02-14 18:38:51 |
Message-ID: | 402E6B3B.3060202@dragonstrider.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> This is a dead end. The --disable-triggers hack is already a time bomb
> waiting to happen, because all dump scripts using it will break if we
> ever change the catalog representations it is hacking. Disabling rules
> by such methods is no better an idea; it'd double our exposure to
> compatibility problems. If we're going to do something about this then
> it needs to be cleaner.
>
> As an implementation issue, I wonder why these things are hacking
> permanent on-disk data structures anyway, when what is wanted is only a
> temporary suspension of triggers/rules within a single backend. Some
> kind of superuser-only SET variable might be a better idea. It'd not be
> hard to implement, and it'd be much safer to use since failures wouldn't
> leave you with bogus catalog contents.
>
> regards, tom lane
I like that idea. I didn't at first, but then I saw the super-user only
bit. Where would I start to implement this? Do we want two separate
properties for rules and triggers, or one to rule them all?
Joseph
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Essington | 2004-02-14 19:04:38 | Cannot read block error. |
Previous Message | Tom Lane | 2004-02-14 17:00:48 | Re: Persistent main memory Storage Manager |