On Tue, Feb 15, 2011 at 12:46 AM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > On Mon, Feb 14, 2011 at 23:30, Stephen Frost <sfr...@snowman.net> wrote: >> > * In assign_csvlog_fields(), we need to cleanup memory and memory context >> > before return on error. >> Fixed this and a couple of similar issues. > > Not yet fixed. Switched memory context is not restored on error. > >> Updated patch attached, git log below. > > Now I mark the patch to "Ready for Committer", > because I don't have suggestions any more. > > For reference, I note my previous questions. Some of them might be TODO > items, or might not. We can add the basic feature in 9.1, and improve it > 9.2 or later versions. > > * csvlog_fields and csvlog_header won't work with non-default log_filename > when it doesn't contain seconds in the format. They expect they can always > open empty log files. > > * The long default value for csvlog_fields leads long text line in > postgresql.conf, SHOW ALL, pg_settings view, but there were no better > alternative solutions in the past discussion. > > * csvlog_fields is marked as PGC_POSTMASTER. It can protect mixed formats > in a csv file on default log_filename, but other similar GUC variables > are usually marked AS PGC_SIGHUP.
I think we should push this whole patch out to 9.2. It seems to me that there are significant unresolved design issues here which need more time and thought than we can realistically give them now. In addition to the above, there is the problem of making the data self-identifying, which I think is really, really important for third-party tools. I am not keen to push a half-baked solution into the tree now that we will have to live with for years. The payoff (getting %U) seems quite out of proportion to the potential downsides of making a change of this type at this late date. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
