On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2016-03-29 12:28:40 -0400, Tom Lane wrote: >>> My proposal would be to invent a new elevel macro, maybe LOG_ONLY, >>> for this purpose. But under the hood it'd be the same as COMMERROR. > >> A couple years back I proposed making thinks like COMERROR into flags | >> ed into elevel, rather than distinct levels. I still think that's a >> better approach; and it doesn't force us to forgo using distinct log >> levels. > > If we invent LOG_ONLY (feel free to bikeshed the name), we could later > redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the > underlying implementation to allow that. But I remain concerned about > dealing with logic like "if (elevel < ERROR)", and I am unconvinced that > there's a near-term use-case here that's compelling enough to justify > finding all the places that do that.
Yeah, I think it's dead certain that such code exists, and, ahem, not only in our tree. I suspect that EDB is not the only organization that has written code that involves comparing error levels. Putting the flags in the low-order bits seems like it might be workable, but I think using a high-order bit is right out. I don't agree that there is no compelling use case for log-only output. I think there's a lot of use case for that, either for general auditing (like pgaudit) or for any specific case where you want to log sensitive information that shouldn't ever be allowed to leak to the client. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
