On Monday, October 15, 2012 10:08:28 PM Christopher Browne wrote: > On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > > On 15 October 2012 19:19, Bruce Momjian <br...@momjian.us> wrote: > >> I think Robert is right that if Slony can't use the API, it is unlikely > >> any other replication system could use it. > > > > I don't accept that. Clearly there is a circular dependency, and > > someone has to go first - why should the Slony guys invest in adopting > > this technology if it is going to necessitate using a forked Postgres > > with an uncertain future? That would be (with respect to the Slony > > guys) a commercial risk that is fairly heavily concentrated with > > Afilias. > > Yep, there's something a bit too circular there. > > I'd also not be keen on reimplementing the "Slony integration" over > and over if it turns out that the API churns for a while before > stabilizing. That shouldn't be misread as "I expect horrible amounts > of churn", just that *any* churn comes at a cost. And if anything > unfortunate happens, that can easily multiply into a multiplicity of > painfulness(es?).
Well, as a crosscheck, could you list your requirements? Do you need anything more than outputting data in a format compatible to whats stored in sl_log_*? You wouldn't have sl_actionseq, everything else should be there (Well, you would need to do lookups to get the tableid, but thats not really much of a problem). The results would be ordered in complete transactions, in commit order. I guess the other tables would stay as they are as they contain the "added value" of slony? Greetings, Andres -- 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
