On 2013-01-17 22:39:18 -0500, Robert Haas wrote: > 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.
I don't have a problem reusing the object access infrastructure at all. I just don't think its providing even remotely enough. You have (co-)written that stuff, so you probably know more than I do, but could you explain to me how it could be reused to replicate a CREATE TABLE? Problems I see: - afaics for CREATE TABLE the only hook is in ATExecAddColumn - no access to the CreateStm, making it impossible to decipher whether e.g. a sequence was created as part of this or not - No way to regenerate the table definition for execution on the remote system without creating libpqdump. Greetings, Andres Freund -- Andres Freund 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