Re: logging statement levels

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>
>

wow. that was nearly 3 months ago ...

>>I wrote:
>>
>>
>>
>>>If nobody is working on this I am prepared to look at it:
>>>
>>>. Allow logging of only data definition(DDL), or DDL and modification
>>>statements
>>>
>>>
>>>
>>
>>Here are some options:
>>
>>1. change the type of "log_statement" option from boolean to string,
>>with allowed values of "all, mod, ddl, none" with default "none".
>>2. same as 1. but make boolean true values synonyms for "all" and
>>boolean false values synonyms for "none".
>>3. keep "log_statement" option as now and add a new option
>>"log_statement_level" with the same options as 1. but default to "all",
>>which will have no effect unless "log_statement" is true.
>>
>>
>
>I like 1.
>
>
>
>>Also, I assume "modification statements" means insert/update/delete, or
>>
>>
>
>Yes.
>
>
>
>>are we talking about DDL mods (like "alter table")?
>>
>>
>
>Alter is DDL.
>
>
>
>>Finally, what about functions that have side effects? It would be nice
>>to be able to detect the statements to be logged at the syntactic level,
>>but it strikes me that that might not be possible.
>>
>>
>
>Not possible.
>
>
>

Subsequent discussion suggested we should add "syntax-errors" to the
allowed values (and I would favor making it the default).

The problem is this - in order to make the decision about whether or not
to log, we need to have parsed the statement (unless the level is set
to "all"). My simple approach, which would mean that the entire patch
would amount to around 100 lines, maybe, plus docco, would have the (I
think) trivial side effect of reversing the order in which a logged
statement and the corresponding parse error log entry appeared. You
objected to that effect, so I stopped work on it.

Now I can think of a couple of different approaches which would not have
this effect:
a. embed a time machine in postgres so we can make a decision based on
information we do not yet have, or
b. find some spot where we can trap the parse error log message before
it is emitted and then first log the statement. That spot is probably
somewhere in src/backend/utils/error/elog.c, but I am not quite sure where.

I have rejected as ugly and unmaintainable monkeying with the parser
itself to produce the desired effect, and I regret that idea a is beyond
my humble abilities :-)

cheers

andrew