On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund <and...@2ndquadrant.com> wrote: > I have no problem requiring C code to use the even data, be it via hooks > or via C functions called from event triggers. The problem I have with > putting in some hooks is that I doubt that you can find sensible spots > with enough information to actually recreate the DDL for a remote system > without doing most of the work for command triggers.
It should be noted that the point of KaiGai's work over the last three years has been to solve exactly this problem. Well, KaiGai wants to check security rather than do replication, but he wants to be able grovel through the entire node tree and make security decisions based on stuff core PG doesn't care about, so in effect the requirements are identical. Calling the facility "event triggers" rather than "object access hooks" doesn't make the underlying problem any easier to solve. I actually believe that the object access hook stuff is getting pretty close to a usable solution if you don't mind coding in C, but I've had trouble convincing anyone else of that. I find it a shame that it hasn't been taken more seriously, because it really does solve the same problem. sepgsql, for example, has no trouble at all checking permissions for dropped objects. You can't call procedural code from the spot where we've got that hook, but you sure can call C code, with the usual contract that if it breaks you get to keep both pieces. The CREATE stuff works fine too. Support for ALTER is not all there yet, but that's because it's a hard problem. -- 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
