> Oliver Jowett wrote:
> > 8.1-beta1 produces some odd results with statement logging enabled when
> > the extended query protocol is used (e.g. when using the JDBC driver).
> > Repeatedly running a simple query with log_statement = 'all' produces this:
...
> > Secondly, running a query that uses portals produces output like this:
> >
> > LOG: statement: PREPARE S_3 AS SELECT * from pg_proc
> > LOG: statement: <BIND> C_4
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> > LOG: statement: EXECUTE C_4 [PREPARE: SELECT * from pg_proc]
> >
> > Comments:
> > - The <BIND> is still fairly content-free.
> > - The EXECUTEs are a bit misleading as the SELECT was actually only run
> > once (there are multiple Execute messages for the same portal). You
> > could infer that there is only one SELECT from the repeated portal name
> > and the lack of an intervening <BIND>, I suppose.
I've put together this prototype to offer more useful messages in the
situation Oliver describes.
Subsequent calls to the same portal are described as FETCHes rather than
as EXECUTEs. The portal name is still given and number of rows is
provided also.
I haven't tested this with the java program supplied, since this is a
fairly short-hack for comments. I'll correct any mistakes before
submission to patches.
Comments?
Best Regards, Simon Riggs
