-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Simon Riggs wrote:
>> One fairly obvious difficulty is how to pass the trigger any meaningful
>> information about what happened (or is about to happen). In the case of
>> TRUNCATE, pretty much everything you need to know is implicit in the
>> event type.
> That's my thought also. I've got a feeling we could do lots of work and
> DDL triggers still wouldn't pass all the information people might want.
>
> I'm not against DDL triggers at all, but I honestly can't see a use for
> them. Maybe there is a general case, or maybe just some specific cases.
> I take Jim's point that many people have asked for them, but I don't
> recall anybody explaining themselves in detail.
Bucardo would use them, but mostly in the same way that the proposed
truncate trigger is being used - notification that a change has occurred,
but without the details. For example, a trigger on a table being replicated
would tell Bucardo to stop immediately the moment a change was made. We
don't really need to know *what* the change was, just that something has
changed that might affect replication. Perhaps the application might then
compare its stored version of the schema to the actual one and figure out
a change, but just a notice that *something* has changed would be a useful
start. +1 and thanks for the truncate trigger, at any rate. :)
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200802032243
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFHpon3vJuQZxSWSsgRA28JAKDNV/qJcr2CqwWD0B1ly6tW0cCxXQCgo9TP
jfDUpXcSi8ET3K6v82AEa44=
=OkQq
-----END PGP SIGNATURE-----
