Re: [PATCH] XLogReader v2
Satoshi Nagayasu <snaga@uptime.jp>
From: Satoshi Nagayasu <snaga@uptime.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, satoshi.nagayasu@gmail.com
Date: 2012-07-23T17:03:11Z
Lists: pgsql-hackers
2012/07/24 1:15, Robert Haas wrote: > On Mon, Jul 23, 2012 at 12:13 PM, Andres Freund <andres@2ndquadrant.com> wrote: >>> Could that be fixed by moving the debugging routines into a separate >>> set of files, instead of having them lumped in with the code that >>> applies those xlog records? >> Its a major effort. Those function use elog(), stringinfo and lots of other >> stuff... I am hesitant to start working on that. >> On the other hand - I think an in-core xlogdump would be great and sensible >> thing; but I can live with using my hacked up version that simply links to the >> backend... > > The stringinfo thing has long been an annoyance to me. libpq has > PQExpBuffer which is the exact same thing. I don't like that we have > two implementations of that in two different code bases, and you have > to remember to spell it right depending on where you are. I'm not > sure exactly what the best way to fix that is, but it sure is a pain > in the neck. Does it make sense to make some static library which can be referred from both the backend and several client utilities, including libpq? Or just a dynamic link be preferred? Despite I do not have a clear idea right now, is it time to start thinking of it? Regards, -- Satoshi Nagayasu <snaga@uptime.jp> Uptime Technologies, LLC. http://www.uptime.jp