Re: pg_restore problems and suggested resolution

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: pg_restore problems and suggested resolution
Дата
Msg-id 402E40D7.6040302@joeconway.com
обсуждение исходный текст
Ответ на Re: pg_restore problems and suggested resolution  (Andreas Pflug <pgadmin@pse-consulting.de>)
Ответы Re: pg_restore problems and suggested resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: pg_restore problems and suggested resolution
Следующее
От: Diego Montenegro
Дата:
Сообщение: Persistent main memory Storage Manager