Re: Proposal: Change of pg_trigger.tg_enabled and adding
| От | Joshua D. Drake |
|---|---|
| Тема | Re: Proposal: Change of pg_trigger.tg_enabled and adding |
| Дата | |
| Msg-id | 45C50BCD.8060508@commandprompt.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Change of pg_trigger.tg_enabled and adding (Jan Wieck <JanWieck@Yahoo.com>) |
| Ответы |
Re: Proposal: Change of pg_trigger.tg_enabled and adding
|
| Список | pgsql-hackers |
Jan Wieck wrote:
> Attached is the implementation of the proposed changes as a patch for
> discussion.
>
> The chosen syntax is backward compatible and uses
>
> ALTER TABLE <tab> ENABLE TRIGGER <trig> (fires on origin - default)
> ALTER TABLE <tab> DISABLE TRIGGER <trig> (disabled)
> ALTER TABLE <tab> ENABLE REPLICA TRIGGER <trig> (fires on replica only)
> ALTER TABLE <tab> ENABLE ALWAYS TRIGGER <trig> (fires always)
>
<snip>
>
> The commands psql and pg_dump are adjusted in a backward compatible
> manner. Although I noticed that psql currently is incompatible with at
> least 8.1 databases due to querying indisvalid on \d.
>
> Comments?
This is interesting. If I understand correctly the idea here is to be
able to determine which triggers will get fired based on the role the
database plays?
E.g; I have a REPLICA TRIGGER and thus I can use that on a
subscriber/slave to take replicated data and create reports automatically.
How do we deal with other problems such as a PROMOTED state?
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
В списке pgsql-hackers по дате отправления: