Andrew Dunstan <[EMAIL PROTECTED]> 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 DETAIL HINT 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match