On 3/29/16 10:18 AM, Tom Lane wrote:
> David Steele <david@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
david@pgmasters.net