On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> Robert Haas escribió: >>> I venture to guess that this is exactly the sort of thing that made >>> Tom argue upthread that we shouldn't be putting a firing point in the >>> middle of the drop operation. Any slip-ups here will result in >>> corrupt catalogs, and it's not exactly future-proof either. > >> Well, is this kind of thing enough to punt the whole patch, or can we >> chalk it off as the user's problem? > > I don't really think that we want any events in the first release that > are defined so that a bogus trigger can cause catalog corruption. > That will, for example, guarantee that we can *never* open up the > feature to non-superusers. I think we'd be painting ourselves into a > corner that we could not get out of.
I agree, although my feelings on this point are actually somewhat stronger than that. > Maybe down the road we'll conclude that there's no other way and we're > willing to put up with an unsafe feature, but I don't want to take that > step under time pressure to ship something in 9.3. I'm opposed to doing it under any circumstances, ever. Right now, there's a very limited number of things which can result in foreign key constraints between system catalogs being violated. So, when it happens, from a support point of view, we don't have many things to investigate. If we add "badly written event triggers" to the list, it's going to open up a can of worms so large it'll be gravitationally rounded. > I thought the proposal was to recompute the set of drop target objects, > and complain if that had changed. Alvaro did that, but it isn't sufficient to prevent catalog corruption. It seems to me that a better way to do this might be to look up the names of all the objects being dropped, as we get rid of them, and pass that information off to the ddl_command_end trigger via something like the pg_dropped_objects() function Dimitri proposed. Then we don't have to deal with the massive grottiness of running a command right in the middle of the deletions, which I continue to maintain will have many as-yet-unforeseen failure modes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
