Simon Riggs wrote:
> Are we sure there is just 3 cases?
I haven't exhaustively checked, but I think those are the main cases.
> Even if case (3) is not that common, I still want to know it is
> occurring, to see what effect or overhead it has.
I don't want it to be more verbose than the other cases when I set
log_statement = all.
> We'll only see the output for case (3) when someone has programmed
> things that way by using setFetchSize.
Can we put extra output in this case into log_statement = verbose only
please?
> (1)
> jdbc parse
> jdbc bind
> jdbc execute
> LOG: statement: SELECT * from pg_proc
> Notice that the parse of the unnamed statement does *not* now generate a
> log record.
What about the syntax error case?
> (2)
> jdbc parse S_1
> LOG: statement: PREPARE S_1 AS SELECT * from pg_proc
> (perhaps this should be logged at BIND time, just like the
> optimization?)
>
> jdbc bind S_1
> jdbc execute
> LOG: statement: EXECUTE <unnamed> [PREPARE: SELECT * from pg_proc]
I do not like logging queries that the driver never sent (the driver
sends neither PREPARE nor EXECUTE).
I also don't see why it's useful to log the statement and portal names.
Can we reword this to what I suggested previously?
LOG: parse statement: SELECT * from pg_proc LOG: execute statement: SELECT * from pg_proc
> (3)
> jdbc prepare S_2
> LOG: statement: PREPARE S_2 AS SELECT * from pg_proc
>
> jdbc bind S_2 to C_2
> jdbc execute C_2
> LOG: statement: EXECUTE C_2 ROWS 42 [PREPARE: SELECT * from pg_proc]
> jdbc next (after cache has run out on 42nd row)
> v3 protocol sends E for Execute, execution halts at 49 rows for this set
> of bind parameters
> LOG: statement: FETCH C_2 ROWS 7
Again I do not like logging synthetic queries that the driver never sent
(PREPARE / EXECUTE / FETCH). BTW, if you do it this way, you could get
the bizarre "PREPARE S_2 AS PREPARE xyz AS SELECT .." result if the
application used PREPARE itself.
I think that logging the second and subsequent Executes is not normally
useful and shouldn't happen when log_statement = all. In that case you
don't need to log the portal name either.
So for the normal case:
LOG: parse statement: SELECT * from pg_proc LOG: execute statement: SELECT * from pg_proc
and for the verbose case perhaps something like:
LOG: parse statement: SELECT * from pg_proc LOG: execute statement (C_2, 42 rows): SELECT * from pg_proc LOG: fetch
statementresults (C_2, 7 rows)
-O
