Re: pg_restore problems and suggested resolution

From: Joe Conway <mail(at)joeconway(dot)com>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joseph Tate <jtate(at)dragonstrider(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_restore problems and suggested resolution
Date: 2004-02-14 15:37:59
Message-ID: 402E40D7.6040302@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Pflug wrote:
> Joe Conway wrote:
>> Christopher Kings-Lynne wrote:
>>>> 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.
>>>
>>> I believe oracle and mssql have ALTER TABLE/DISABLE TRIGGER style
>>> statements...
>>
>> Oracle does for sure, but I can tell you that I have seen people
>> bitten by triggers inadvertantly left disabled before...I think Tom
>> has a good point.
>
> Might be, but disabled triggers are not only useful when restoring a
> database. We need this, and supporting this without hacking would be
> helpful.

I didn't dispute the fact that disabling triggers (without unsupported
hacks) is useful. I did agree with Tom that doing so with "permanent"
commands is dangerous. I think the superuser-only SET variable idea is
the best one I've heard for a way to support this.

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Diego Montenegro 2004-02-14 15:45:05 Persistent main memory Storage Manager
Previous Message Andreas Pflug 2004-02-14 10:50:58 Re: pg_restore problems and suggested resolution