Tom Lane wrote:
> 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
>
> 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.
>
I'm not sure that putting all this into a single extra field would be so
wrong. As for an array of text, that doesn't seem very portable. I don't
think we should assume that Postgres is the only intended program
destination of CSV logs.
> 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.
>
Seems like over-egging the pudding to me somewhat, but OK if we decide
to go with a whole bunch of fields.
> 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?
>
>
>
I think for sanity's sake we need one (maximal) format. I'm not so
concerned about disk space. It's not like this is the only logging
option available.
cheers
andrew
