Robert Haas <robertmh...@gmail.com> writes: > It seems to me (and it may seem differently to other people) that what > most people who want to trap DDL events really want to do is either
[ detailed analysis, mostly right on spot ] Yeah, I'm proposing a rather crude tool. I think it's still solving real problems we have now, and that no other tool nor design is solving for us. So for me the real questions are: - do we want the feature in that form? - are we avoiding to paint ourselves into a corner? I think both answers are positive, because I want the feature bad enough to have spent time working on it, and it's able to solve two problems in one stone already. Also, the only way to have that feature in an extension implementing ProcessUtility_hook is duplicating what I've been doing, minus grammar support (just because you can't). Also that's not the kind of efforts that either slony or londiste will put into their own project, the amount of work wouldn't be justified for this only return, as history is telling us. (there's a game changer here though, which is the idea of doing “command triggers” as opposed to “ddl triggers” or even “catalog triggers”, thanks Jan) Then, we can expand the trigger function signature down the road and keep the current one as a compatibility support. For example we could add a cascading boolean argument and decide whether or not to call the trigger function when cascading based upon the trigger's procedure signature. So I believe it's somewhat coarse or crude, still useful enough, and not painting us into a corner. > using a security definer function as a DDL instead-of trigger is an > interesting one, but does that leave newly created objects owned by > the wrong user? Or what if you want user A to be able to do some but > not all of the things user B can do? Drilling an optimally-sized hole > through the existing permissions system is unfortunately not very > simple. You can still use ALTER OBJECT … OWNER TO …; from within the security definer function to allow the setup you're interested into. I guess that you can still have some conditional on current_user from the code too, but I didn't check that we have user id and effective user id both available from the SQL level (yet). All in all, I understand your reticence here, but I'm not sharing it, Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers