The current definition of log_statement has no problem because we print
the whole string, once, before parsing starts. If you put a printout
into the per-parse-tree loop then I think you are going to get multiple
printouts of the same string.
I didn't intend to - I intended to do it before that. All or nothing deal. e.g. if they want DML then if any of the queries has insert/update/delete/copy they get the whole query string.
You could add some state to prevent more than one printout per querystring, but even then you'll get complaints "I asked for DDL only, why did it print this SELECT?". ISTM the only way to make it "work" without obvious implementation artifacts is to actually break down the string into individual commands, which is more work than I think this feature is worth.
Well, it gets worse than that when you consider that I tend to put all my DML inside a stored proc and have the client call "select myproc(args)".
However, people have asked for a facility to filter out stuff, especially to filter out select statements they are not interested in.
I agree that it is simpleminded, and I wouldn't use it. But we can put warnings about likely effects in the docs.
Or we can abandon the whole idea and remove it from the TODO list. I'm not burning up with desire to do this.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
