Bruce Momjian wrote:

Andrew Dunstan wrote:


Bruce Momjian wrote:



Andrew Dunstan wrote:




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.





If I had to make a choice I'd go the other way.



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

Reply via email to