On 01/14/2011 11:48 AM, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Andrew Dunstan<andrew@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... :(
>
>
I'm not sure I really want to make it that flexible :-)
To deal with the issue Tom's referring to, I think it would be
sufficient if we just allowed users to suppress production of certain
columns (as long as we never do anything so evil as to add a new column
in the middle).
There are some other issues with the format. I know Josh has bitched
about the presence of command tags in certain fields, for example.
cheers
andrew
