Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I was thinking of it as being strictly a field list. I don't know
>> whether it's really practical to borrow log_line_prefix's one-character
>> names for the fields (for one thing, there would need to be names for
>> all the existing CSV columns, not all of which equate to log_line_prefix
>> escapes);
> I'm not really happy about the idea that you can only get certain
> information in a log file if you use CSV format.
I said no such thing! The point here is that there is a great deal of
stuff in the textual log format that is not governed by log_line_prefix,
so log_line_prefix provides no precedent for naming it: the error level,
the SQLSTATE, the primary message, the detail, the hint, etc, all come
out without any connection to log_line_prefix. In CSV all of those
already exist as columns. If we want users to be able to control which
CSV columns get emitted, they'll need to be able to name those columns,
and log_line_prefix doesn't provide any precedent for that.
> I also don't know
> that there's really any particular reason log_line_prefix's names
> have to be one character.
Well, it's pretty much conventional for %-escapes to be that way,
though I agree we're kind of straining the system already.
> I do like the idea of having just a field list though, to keep things
> simple for the CSV users, and we could also pre-process the list into
> flag variables or a bitmask or similar to be able to quickly check if a
> certain field should be included or not. I'm not really keen about how
> log_line_prefix currently parses the direct user-provided syntax every
> time; strikes me as inefficient.
For log_line_prefix I'm not sure you could do a lot better. I agree
that a field name list for CSV would have to be preprocessed somehow for
efficiency.
regards, tom lane
