Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Well, if we want to cram all that stuff in there, how shall we do it?
>> It seems wrong to put all those lines into one text field, but I'm
>> not sure I want to add six more text fields to the CSV format
>> either. Thoughts?
> Really? Six? In any case, would that be so bad? It would mean six extra
> commas per line in the log file, and nothing much in the log table
> unless there were content in those fields.
Yeah --- the lines output in the plain-stderr case that are not covered
in the other are
DETAILHINT QUERY (this is an internally-generated query that failed)CONTEXT (think "stack
trace")LOCATION (reference to code file/line reporting the error)STATEMENT (user query that led to the error)
One issue here is that CONTEXT is potentially multiple lines. I'm not
sure that there is much we can do about that, especially not at the last
minute. If we had some time to rewrite internal APIs it might be fun to
think about emitting that as array of text not just text, but I fear
it's much too late to consider that now.
Another thing that I notice is that the CSV code emulates a couple of
not-very-orthogonal behaviors of send_message_to_server_log():
substituting "missing error text" for a NULL error field, and emitting
cursor pos as a tack-on to the error text instead of a separate field.
I think both of those are less than defensible. So if you're willing
to entertain redefining the CSV column set at this late date, I'd
propose throwing in a seventh new field too: CURSORPOS.
Another thing: for stderr output, we have various log verbosity options
that determine whether these additional fields get printed. Should
those options also function in the CSV-output case, or are we just going
to do our best to exhaust disk space as fast as possible all the time?
regards, tom lane
