Обсуждение: velog + vereport?
Hi,
When writing code which should be able to run inside and outside a normal
backend environment its sometimes useful to be able add a wrapper arround
elog/ereport for when executing inside the backend.
Currently that requires relatively ugly macro surgery and/or recompiling the
file. I suggest adding velog/vereport or elog_va/vereport_va to make such
wrappers easier (still not easy though).
The aim would be able to do something like:
#define my_elog \ elog_wrapper_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), \ elog_wrapper_finish
And then
void
elog_wrapper_finish(int elevel, const char *fmt, ..)
{ va_list args; va_start(args); velog(elevel, fmt, args); va_end(args);
}
when inside the backend
And something like:
void elog_wrapper_finish(int elevel, const char *fmt, ..)
{ va_list args; fprintf(stderr, "...", my_elog_file, my_elog_line, my_elog_func); va_start(args);
vfprintf(stderr,fprintf, args); va_end(args);
}
Comments? Better idea (please!)?
This would be easier if we had vararg macros, but I don't see me winning that
argument :P
Greetings,
Andres
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
Andres Freund <andres@2ndquadrant.com> writes:
> When writing code which should be able to run inside and outside a normal
> backend environment its sometimes useful to be able add a wrapper arround
> elog/ereport for when executing inside the backend.
> Currently that requires relatively ugly macro surgery and/or recompiling the
> file. I suggest adding velog/vereport or elog_va/vereport_va to make such
> wrappers easier (still not easy though).
Um ... and that accomplishes what? You wouldn't have velog/vereport
outside the backend either. If you were going to clone those in some
form in the external environment, you might as well clone the existing
elog infrastructure functions.
regards, tom lane
On Friday, October 12, 2012 02:48:42 PM Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > When writing code which should be able to run inside and outside a normal > > backend environment its sometimes useful to be able add a wrapper arround > > elog/ereport for when executing inside the backend. > > Currently that requires relatively ugly macro surgery and/or recompiling > > the file. I suggest adding velog/vereport or elog_va/vereport_va to make > > such wrappers easier (still not easy though). > > Um ... and that accomplishes what? You wouldn't have velog/vereport > outside the backend either. If you were going to clone those in some > form in the external environment, you might as well clone the existing > elog infrastructure functions. The advantage is that if you something velog-ish you can have a function which accepts vararg arguments and forwards them. E.g. xlogreader->error(ERROR, "...", argument, argument); Which is a callback using vfprintf(stderr) if running standalone or a callback calling vereport(). (obviously you need some more magick to also forward file/line/function, but its not too hard) Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> On Friday, October 12, 2012 02:48:42 PM Tom Lane wrote:
>> Um ... and that accomplishes what? You wouldn't have velog/vereport
>> outside the backend either. If you were going to clone those in some
>> form in the external environment, you might as well clone the existing
>> elog infrastructure functions.
> The advantage is that if you something velog-ish you can have a function which
> accepts vararg arguments and forwards them.
> E.g.
> xlogreader->error(ERROR, "...", argument, argument);
Meh. I can't get excited about that, but in any case, that looks like
it would only justify a varargs version of errmsg(), not the entire
ereport infrastructure.
regards, tom lane
On Friday, October 12, 2012 04:59:39 PM Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On Friday, October 12, 2012 02:48:42 PM Tom Lane wrote: > >> Um ... and that accomplishes what? You wouldn't have velog/vereport > >> outside the backend either. If you were going to clone those in some > >> form in the external environment, you might as well clone the existing > >> elog infrastructure functions. > > > > The advantage is that if you something velog-ish you can have a function > > which accepts vararg arguments and forwards them. > > E.g. > > xlogreader->error(ERROR, "...", argument, argument); > > Meh. I can't get excited about that, but in any case, that looks like > it would only justify a varargs version of errmsg(), not the entire > ereport infrastructure. Yes, that sounds good enough. Are you vetoing that idea (in that case I won't pursue it) or just aren't excited about it? Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> On Friday, October 12, 2012 04:59:39 PM Tom Lane wrote:
>> Meh. I can't get excited about that, but in any case, that looks like
>> it would only justify a varargs version of errmsg(), not the entire
>> ereport infrastructure.
> Yes, that sounds good enough. Are you vetoing that idea (in that case I won't
> pursue it) or just aren't excited about it?
Well, I'm not excited about adding more elog.c infrastructure in advance
of having a use-case in the core code --- how would we know if it got
broken? That's not meant as an absolute veto, but I'm not terribly
comfortable about adding code speculatively.
regards, tom lane
On Friday, October 12, 2012 06:02:44 PM Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On Friday, October 12, 2012 04:59:39 PM Tom Lane wrote: > >> Meh. I can't get excited about that, but in any case, that looks like > >> it would only justify a varargs version of errmsg(), not the entire > >> ereport infrastructure. > > > > Yes, that sounds good enough. Are you vetoing that idea (in that case I > > won't pursue it) or just aren't excited about it? > > Well, I'm not excited about adding more elog.c infrastructure in advance > of having a use-case in the core code --- how would we know if it got > broken? That's not meant as an absolute veto, but I'm not terribly > comfortable about adding code speculatively. Oh, thats fine. I will submit it together with the code thats using it (next xlogreader draft). Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services