Robert Haas <robertmhaas@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
