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
