On Monday, September 17, 2012 04:08:01 PM Tom Lane wrote: > Heikki Linnakangas <hlinnakan...@vmware.com> writes: > > On 17.09.2012 13:01, Andres Freund wrote: > >> It seems we would need one additional callback for both approaches like: > >> ->error(severity, format, ...) > >> For both to avoid having to draw in elog.c. > > > > Yeah. Another approach would be to return the error string from > > ReadRecord. The caller could then do whatever it pleases with it, like > > ereport() it to the log or PANIC. I think I'd like that better. > > I think it's basically insane to imagine that you can carve out a > non-trivial piece of the backend that doesn't contain any elog calls. > There's too much low-level infrastructure, such as palloc, that could > call it. Even if you managed to make it safe at the instant the feature > is committed, the odds it would stay safe over time are negligible. If you start relying on palloc all hope is gone anyway. I "only" want a standalone XLogReader because thats just too damn annoying/hard to duplicate in standalone code. There are several very useful utilities out there that are incomplete and/or unreliable for that reason. And loads of others that haven't been written because of that.
That is one of the reasons - beside finding the respective xlog.c code very hard to read/modify/extend - why I wrote a completely standalone xlogreader. One other factor was just learning how the hell all that works ;) I still think the interface that something plain as the proposed XLogReadRecord() provides is too restrictive for many use-cases. I aggree that a wrapper with exactly such an interface for xlog.c is useful, though. > Furthermore, returning enough state for useful error messages back out > of multiple layers of function call is going to be notationally messy, > and will end up requiring complicated infrastructure barely simpler than > elog anyway. Hm. You mean because of file/function/location? > It'd be a lot better for the wal-dumping program to supply a cut-down > version of elog than to try to promise that all errors will be returned > back from ReadRecord. Well, I suggested a ->error() callback for that reason, that seems relatively easy to wrap. 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
