Re: statement logging / extended query protocol issues

Oliver Jowett wrote:
> Bruce Momjian wrote:
>
> > I think it is more verbose because no FETCH is logged in this type of
> > prepare/execute. The goal, I think, is for these type of queries to
> > look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
>
> I do not understand why this is a useful thing to do as part of
> log_statement.
>
> My point is that given JDBC code like this:
>
> Statement s = connection.createStatement();
> ResultSet rs = s.executeQuery("SELECT * FROM pg_proc");
> while (rs.next()) {
> // Process results
> }
>
> it seems that the least surprising thing to get logged is simply "SELECT
> * FROM pg_proc".
>
> I don't see how logging a synthetic PREPARE/EXECUTE/FETCH sequence (and
> DECLARE, now?) is useful. They're not necessarily syntactically correct,
> and they're certainly not queries that were actually sent to the
> backend. I thought log_statement was meant to answer the question "what
> queries were submitted to the backend?", rather than to provide a trace
> of protocol-level activity..

Well, from the application writer perspective, you are right it doesn't
make sense, but this is only because jdbc is using prepare internally.
If you were to have written it in libpq, it would make sense, I think,
and internally, this is what is happening. We can't assume only
interface libraries like jdbc are using this feature.

As far as I understand things, the protocol-level prepare/execute is
identical to the SQL-level prepare/execute, except that there is no need
to parse the execute, so it should log like the SQL-level statements, if
possible.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073