On Tue, Oct 15, 2013 at 10:09 AM, Hannu Krosing <ha...@krosing.net> wrote: >> I don't see how you can fail to know what "all" is. > We instinctively know what "all" is - as in the famous case of buddhist > ordering a > hamburger - "Make me All wit Everything" :) - but the requirements of > different replications systems vary wildly.
That's true to some degree, but let's not exaggerate the degree to which it is true. > For multi-master / conflict resolution you may also want all old > values to make sure that they have not changed on target. The patch as proposed doesn't make that information available. If you want that to be an option, now would be the right time to argue for it. > for some forms of conflict resolution we may even want to know > the database user who initiated the operation. and possibly even > some session variables like "very_important=yes". Well, if you have requirements like logging very_important=yes, then you're definitely into the territory where you need your own output plugin. I have no problem telling people who want that sort of thing that they've got to go write C code. What I'm trying to do, as Larry Wall once said, is to make simple things simple and hard things possible. The output plugin interface accomplishes the latter, but, by itself, not the former. >> And I think we can facilitate that without too much work. > just provide a to-csv or to-json plugin and the crappy perl guys > are happy. Yep, that's exactly what I'm advocating for. -- 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