<p dir="ltr">On 6 Sep. 2016 17:57, "Pavan Deolasee" <<a
href="mailto:pavan.deolasee@gmail.com">pavan.deolasee@gmail.com</a>>wrote:<br /> ><br /> ><br /> ><br />
>On Tue, Sep 6, 2016 at 3:06 PM, Craig Ringer <<a
href="mailto:craig.ringer@2ndquadrant.com">craig.ringer@2ndquadrant.com</a>>wrote:<br /> >><br /> >><br
/>>> I think it's worth looking at how Java handles logging. We can't achieve an exact parallel in C as we don't
reallyhave a class hierarchy ... but we do have subsystems roughly grouped by file and directory structure.<br />
><br/> > Sure. In some large, popular enterprise softwares I've worked with many years ago, we used to define
moduleswithin each source file and then manually assign distinct integer IDs to each message and then provide various
utilitiesto turn on/off specific messages or range of messages within a module.<p dir="ltr">Yeah, there same has been
discussedfor Pg many times and firmly shot down each time. I certainly see the argument against making specific elog
callspart of a sort of api people might expect to be stable ish. That's what we have ERRCODE / SQLSTATE for right?
Concernsabout backpatch pain were also raised. Probably more. I'm not especially for or against it myself, just saying
thatbased on past discussion such a proposal isn't likely to fly.<p dir="ltr">I think something automatic that we
clearlydefine as unstable and not to be relied upon would be preferable. Plus we already have much of the
infrastructurein elog.c as used by errcontext etc.<p dir="ltr">> Well, __FUNCTION__ expands to function name and
lookupbased on string identifiers will always be costly, especially if you want to sprinkle the code with lot many
debugmessages. Same with __FILE__. I believe we need an unique integer constant to make it a fast, O(1) lookup. I
couldn'tfind any other method to do that when I wrote the facility and hence did what I did.<p dir="ltr">Yeah. High
performancelogging and filtering isnt easy. Looking at existing C logging libraries with dynamic filtering might be
informative.Though I can't imagine there being agreement to adopt one, this must be a reasonably solved problem...<p
dir="ltr">><br/> > Thanks,<br /> > Pavan<br /> > -- <br /> > Pavan Deolasee <a
href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a><br /> > PostgreSQL Development, 24x7 Support,
Training& Services<br />