Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:If I had to make a choice I'd go the other way.
Unless I'm missing something, this patch has the effect that with values of "ddl" or "mod" for log_statement, a statement with a parse error will not be logged, which was what I hoped to avoid.
Right. The query type can't be determined during a syntax error because the parser couldn't identify the supplied command. I think that is fine.
What it does allow is to for 'all' to display the command before the syntax error.
Uh, what other way?
reverse the order rather than suppress the message.
However, I think with a little extra work it might be possible to have both.
Right now, the way it is done, only a real syntax error skips logging. If you referenced an invalid table or something, it does print the log just before the invalid table name mention.
How would we test the command type before hitting a syntax error? I can't think of a way, and I am not sure it would even be meaningful.
I agree that you can't test the statement type on a parse error. But that doesn't mean to me that "mod" should suppress logging statements with syntax errors. In fact, after the discussion surrounding this I thought the consensus was to have these things as additive rather than just one level selected.
How to do it in the order you prefer? I would trap the parse error and log the statement before emitting the error log.
If I find a simple way I'll submit a further patch.
Certainly your patch contains the guts of what needs to be done in any case.
cheers
andrew
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
