* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan <and...@dunslane.net> writes: > > I think it's time to revisit the design of CSV logs again, now we have > > two or three releases worth of experience with it. It needs some > > flexibility and refinement. > > It would definitely be nice to support optional columns a little better. > I'm not even sure whether the runtime overhead is worth worrying about > (maybe it is, maybe it isn't, I have no data). But I do know that > adding a column to the CSV output format spec causes a flag day for > users. How can we avoid that?
My first thought would be to have a 'log_csv_format' GUC that's very
similar to 'log_line_prefix' (and uses the same variables if
possible..). We could then ship a default in postgresql.conf that
matches what the current format is while adding the other options if
people want to use them.
If we could have all the processing to generate that line go through the
same function for log_line_prefix and log_csv_format, that'd be even
better. Makes me tempted to throw out the current notion of
'log_line_*prefix*' and replace it with 'log_line_*format*' to match
exactly the 'log_csv_format' that I'm proposing. That'd undoubtably
cause more user headaches tho... :(
Thanks,
Stephen
signature.asc
Description: Digital signature
