Re: [PATCH] XLogReader v2
От | Satoshi Nagayasu |
---|---|
Тема | Re: [PATCH] XLogReader v2 |
Дата | |
Msg-id | 500D83CF.5010701@uptime.jp обсуждение исходный текст |
Ответ на | Re: [PATCH] XLogReader v2 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] XLogReader v2
|
Список | 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
В списке pgsql-hackers по дате отправления: