On 2013-01-17 11:15:24 -0500, Robert Haas wrote: > As a further example, suppose that in 9.4 (or 9.17) we add a command > "DROP TABLES IN SCHEMA fred WHERE name LIKE 'bob%'". Well, the > logging trigger still just works (because it's only writing the > statement, without caring about its contents). And the replication > trigger still just works too (because it will still get a callback for > every table that gets dropped, even though it knows nothing about the > new syntax). That's very powerful. Of course, there will still be > cases where things have to change, but you can minimize it by clean > definitions. > > It pains me that I've evidently failed to communicate this concept > clearly despite a year or more of trying. Does that make sense? Is > there some way I can make this more clear? The difference seems very > clear-cut to me, but evidently I'm not conveying it well.
Well, I didn't manage to follow the topic with the level of detail I would have liked to/should have so its very well possible that I missed a proposal of how to implement that concept in a way you like? With some squinting you can actually see the proposed ddl_trace callsite as exactly that kind of replication trigger, but with a worse name... Without piggy-backing on the internal commands generated - which currently seems to be achieved by passing everything through ProcessUtility, but could work in a quite different way - and reconstructing sql from that I don't immediately see how you want to do this? 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
