On 3/29/16 10:18 AM, Tom Lane wrote:
David Steele <da...@pgmasters.net> writes:
On 3/28/16 2:00 PM, Tom Lane wrote:
One idea is to invent a new elevel which is never sent to the client ---
analogously to COMMERROR, though probably much higher priority than that,
maybe the same priority as LOG. If there actually is a use for a range of
elevels on errhidefromclient'd messages, that wouldn't work very well of
course. Or we could consider having a flag bit that is OR'd into the
elevel <...>
I think a flag would be more flexible than introducing a new log level.
I thought about this some more, and while the flag-bit approach definitely
has some attraction, it also has a big problem: there are lots of places
with code like "if (elevel >= ERROR)" which would be at risk of getting
confused, and I'm not confident we'd find them all. We could possibly
dodge that by shifting the elevel constants up a couple of bits and
putting the flag in the LSB rather than a high-order bit; but that's a
bit icky/risky too.
Repurposing COMMERROR is definitely starting to seem like a low-impact
solution compared to these others. Under what circumstances would you
be wanting hide-from-client with an elevel different from LOG, anyway?
In pgaudit the log level for audit messages is user configurable but
this was mostly added for testing purposes on the client side. I don't
think it would be a big deal to force the level to LOG when client
output is suppressed.
The advantage of this approach is that it will also work on older
versions of PG so I don't have to wait to introduce the feature. I'll
try it out and see how it goes.
Thanks,
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
