On Tue, Mar 29, 2016 at 12:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. > > Yeah, that's exactly my concern: it'd likely break third-party code > not only our own. > >> 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. > > We'd need a bit more investigation. I'm not exactly sure that we can > renumber the existing elevel codes at all without breaking things > (guc.c's management of client_min_messages et al would be a place > to look at, for instance). But if someone wants to pursue it, > the general concept seems somewhat sane. > > Looking back at the earlier thread Andres mentioned, I see that he was > specifically on about being able to do ereport(ERROR | LOG_NO_CLIENT), > which I've got a problem with because of the point about not breaking > wire-protocol expectations. You could maybe define such a case as > substituting a text like "error message is hidden" when sending the > error to the client? But the draft patch he had didn't address that > point, and it doesn't look like he thought about the elevel-comparisons > issue either. > >> 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. > > Oh, I agree that there's a compelling use-case for LOG | > ERR_HIDE_FROM_CLIENT. I'm less certain that there's a use-case > for supporting such a flag across all elevels that is strong enough > to justify all the work we'd have to do to make it happen. Basically, > my point is that LOG_ONLY achieves 95% of the benefit for probably > 0.01% of the work.
If LOG_ONLY is what we can get right now, I'm happy to take the money and run. -- 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
