On 6 December 2012 18:31, Andres Freund <and...@2ndquadrant.com> wrote: > On 2012-12-06 18:21:09 +0000, Simon Riggs wrote: >> On 6 December 2012 00:46, Robert Haas <robertmh...@gmail.com> wrote: >> > On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> >> Yes, but it is also the trigger writers problem. >> > >> > Maybe to some degree. I don't think that a server crash or something >> > like a block-read error is ever tolerable though, no matter how silly >> > the user is with their event trigger logic. If we go down that road >> > it will be impossible to know whether errors that are currently >> > reliable indicators of software or hardware problems are in fact >> > caused by event triggers. Of course, if an event trigger causes the >> > system to error out in some softer way, that's perfectly fine... >> >> How are event triggers more dangerous than normal triggers/functions? > > Normal triggers aren't run when the catalog is in an in-between state > because they aren't run while catalog modifications are taking place.
"in-between state" means what? And what danger do you see? If its just "someone might write bad code" that horse has already bolted - functions, triggers, executor hooks, operators, indexes etc I don't see any difference between an event trigger and these statements... BEGIN; ALTER TABLE x ...; SELECT somefunction(); ALTER TABLE y ...; COMMIT; -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
