Andres & those involved in the 9.3 Command triggers:
You may want to consider changing the command TRIGGER into a command
FILTER and possibly post processing TRIGGER that
is determined to be called INSIDE the FILTER. Or some way to pass
information between the FILTER and the post processing trigger.
Also, something information as to whether a series of statements was
ROLLED BACK would be helpful.
How to rebuild the parsetree so external replication could catch a clue
that all of the last series of updates was actually rolled back!
For example, I want to enforce a policy where all DROP TABLE xxxx
commands become ALTER TABLE xxxx RENAME to SIGyyyyy
All DROP TABLE Sigyyyy commands are not changed so that the SIG tables
actually drop. (Almost like a TRASH Can for postgresql!)
ALL TRUNCATE TABLE xxxx Become ALTER TABLE xxxx RENAME to SIGyyyyy AND
THEN CREATE TABLE xxxx SELECT AS SIGyyyy
This way, there is not possible way to have to enforce a Waiting period
for replication to begin its work when errant DROP / TRUNCATES occur.
All of this is important for Easy Setup/Initiation, Self-Healing, Fault
Tolerant, Scaleable, INEXPENSIVE, External REPLICATION, a larger subject
indeed.
I want CLOUD behavior without CLOUD prices.
Anybody who is working on the 9.3 COMMAND TRIGGER, drop me a note if you
wish.
marco
On 9/21/2012 3:41 PM, Andres Freund wrote:
> Hi,
>
> On Friday, September 21, 2012 11:06:46 PM md@rpzdesign.com wrote:
>> Thanks for the link on the GIT patch code.
>>
>> I did a big major domo search and found some stuff related to command
>> triggers:
>>
>> http://archives.postgresql.org/pgsql-hackers/2012-03/msg00169.php
>>
>> "Look into the new event triggers started recently." -
>>
>> Are these command triggers currently in the 9.2.0 code base or is it in
>> a alpha 9.2.1xxx?
> Its not in 9.2 and will only be in 9.3
>
> Andres
