Re: [PROPOSAL] Client Log Output Filtering
От | Tom Lane |
---|---|
Тема | Re: [PROPOSAL] Client Log Output Filtering |
Дата | |
Msg-id | 368.1459261119@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Client Log Output Filtering (David Steele <david@pgmasters.net>) |
Ответы |
Re: [PROPOSAL] Client Log Output Filtering
|
Список | pgsql-hackers |
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? regards, tom lane
В списке pgsql-hackers по дате отправления: