On Thu, Feb 23, 2006 at 09:35:50AM +0200, Hannu Krosing wrote: > Being able to put triggers on system tables to record changes together > with ON COMMIT trigger to gather and process this recorded data would > give you 99.9% of needed functionality. <snip> > Just being able to create AFTER triggers (no need to muck with DDL > commands, just record their effects) would go a long way.
Agreed. I'd much rather start with a small subset of possible functionality and go from there rather than have nothing because we can't come up with a fully-baked implementation. So, what if the initial implimentation is limited to: Per-row and per-statement AFTER triggers Rules Does that sound reasonable? One thing about this that I don't like... it means we'd be pretty formally exposing the catalogs as an API. Perhaps it would be better to use either info_schema or newsysviews as an API, though I have no idea how hard it would be to allow rules or triggers on a view. Of course another possibility is to create an entirely different API. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
