Re: fix log_min_duration_statement logic error
От | Bruce Momjian |
---|---|
Тема | Re: fix log_min_duration_statement logic error |
Дата | |
Msg-id | 200310052011.h95KBsd12367@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: fix log_min_duration_statement logic error (Rod Taylor <rbt@rbt.ca>) |
Ответы |
Re: fix log_min_duration_statement logic error
|
Список | pgsql-patches |
Rod Taylor wrote: -- Start of PGP signed section. > > > I have not heard from you why we should make it harder (split across two > > > lines), except for consistency with log_statement and log_duration > > > outputs. > > I think this is a perfectly good argument. Don't make writing the tools > to parse the log more difficult than necessary. > > Rather than making the log files look nice, lets add a module to PgAdmin > that can read it and display it in a user friendly manner (with > abilities like sorting queries by execution time!). > > > Should we instead convert newlines to "\n" and output the query as a > > single line? Do we have lots of other multi-line outputs in the log > > files? > > Please don't. Or if you do, don't data unless you intend to escape > special characters (in this case \) at the same time so we can convert > it back to the original state. OK, I coded to convert newline to "\n", carriage return to "\r", and backslash to "\\". This might cause confusion if you are doing: INSERT INTO tab VALUES ('\b'); which outputs as: INSERT INTO tab VALUES ('\\b'); but I see your point that we should be accurate. Actual output is: LOG: duration: 1.762 ms; insert into ii values ('\\b'); Another example: LOG: duration: 4.228 ms; select *\nfrom pg_language; -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: