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


---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to