Re: defer statement logging until after parse
От | Andrew Dunstan |
---|---|
Тема | Re: defer statement logging until after parse |
Дата | |
Msg-id | 1534.24.211.141.25.1079105473.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: defer statement logging until after parse (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: defer statement logging until after parse
|
Список | pgsql-patches |
Bruce Momjian said: > Andrew Dunstan wrote: >> >> >> Bruce Momjian wrote: >> >> >The problem I see with this patch is that it doesn't print the error >> >query on a syntax error. That seems wrong. >> > >> >> It does print it. In fact the example I gave below which is from a >> real trace shows it being printed. It is just printed after the error >> message rather than before. >> >> You solution doesn't appear to address the problem of what to do if >> they ask for only DDL and one of those generates a syntax error. > > My comment was that if they type "UP8ATE", and it is a syntax error, we > have no way to know if it was a DDL or not, so we don't print it. > > My idea was to take log_statement, and instead of true/false, have it > be all, ddl, mod, or off/none/false(?). You keep the existing test for > log_statement where it is, but test for 'all' now, and after parse, you > check for ddl or mod, and print in those cases if the tag matches. > > If they want ddl and errors, they can use log_min_error_statement to > see just statement error, and set log_statement accordingly. > The problem is that you are anticipating my solution for the selectivity issue before I have written or submitted it. My question was different and narrower - namely will the patch I sent, as it stands, and forgetting the selectivity issue for the moment, break anything? When I actually send in a patch to implement statement log selectivity, I will give you free license to pull it to bits to your heart's content. cheers andrew
В списке pgsql-patches по дате отправления: