Re: pg_dump with disable trigger
| От | David G. Johnston |
|---|---|
| Тема | Re: pg_dump with disable trigger |
| Дата | |
| Msg-id | CAKFQuwZP0qH_0Scy+=mTBybN+pmhCpnziX-Us0kwSc8ejPwMPg@mail.gmail.com обсуждение исходный текст |
| Ответ на | pg_dump with disable trigger (Soni M <diptatapa@gmail.com>) |
| Ответы |
Re: pg_dump with disable trigger
|
| Список | pgsql-bugs |
Hello All,I think I found bug on pg_dump 9.6.8.The bug arise when using pg_dump with --disable-trigger option.
The command just :
pg_dump -f /tmp/test_disable_trigger.sql -a -b --disable-triggers -t some_table some_databaseOn the resulted script, it simply didALTER TABLE public.some_table DISABLE TRIGGER ALL;COPY commandALTER TABLE public.some_table ENABLE TRIGGER ALL;This become a problem, when the destination table already has Disabled user triggers, it gets enabled by the dump script.
I would classify this as a limitation of the concept as opposed to a bug. I was going to say a bit more but I'm not that fluent with disabled triggers mode in dump/restore setups. I would advise using pg_restore and leaving the disable triggers option of the pg_dump command. It lacks sufficient information to write an appropriate script for an unknown target server.
If you have issues with pg_restore those would be more easily be deemed as bugs.
FWIW we have a "SET LOCAL" command that results in GUC variables being restored to their state post-transaction; we'd need a similar command for pg_dump to work properly.
It also altered another kind of trigger like Triggers firing on replica only, get altered to ordinary triggers.
This seems like a bug - though I'm not going to be confirming the behavior and you haven't provided evidence.
David J.
В списке pgsql-bugs по дате отправления: