Re: defer statement logging until after parse

Tom Lane wrote:

>
>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