On 01/14/2011 11:48 AM, Stephen Frost wrote:
* 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... :(
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
