Re: PGStatement#setPrepareThreshold - Mailing list pgsql-jdbc

From Bruce Momjian
Subject Re: PGStatement#setPrepareThreshold
Date
Msg-id 200608041615.k74GF2M16894@momjian.us
Whole thread Raw
In response to Re: PGStatement#setPrepareThreshold  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: PGStatement#setPrepareThreshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PGStatement#setPrepareThreshold  (Csaba Nagy <nagy@ecircle-ag.com>)
List pgsql-jdbc
Dave Cramer wrote:
>
> On 3-Aug-06, at 11:55 PM, Bruce Momjian wrote:
>
> > Dave Cramer wrote:
> >>
> >> On 3-Aug-06, at 6:14 PM, Oliver Jowett wrote:
> >>
> >>> Dave Cramer wrote:
> >>>
> >>>> If that's the case then the driver is not doing what it's supposed
> >>>> to be doing. It should be using the named portal (S_3) to do the
> >>>> insert.
> >>>
> >>> No, the driver is fine. It is using a named statement (S_3) but an
> >>> unnamed portal (because it is going to fetch all the data in one go
> >>> and doesn't need to retain the portal after execution)
> >>>
> >>> If your query met the conditions for using a portal-based
> >>> ResultSet, you'd see it use a named portal as well as a named
> >>> statement.
> >>
> >> Thanks for clarifying that Oliver, the logs are still misleading in
> >> that they don't name the statement used in the bind message.
> >
> > Current CVS has:
> >
> >      (errmsg("statement: [protocol] <BIND> %s", portal_name)));
>
> Bind also has a statement name, as well as a portal name ?
>
> Ideally I'd like to see the parameters which were bound and the
> types, but I suspect I'm reaching here.

Right, but do we want to repeat the statement for every bind case?

The bind parameter printing is on the TODO list.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: PGStatement#setPrepareThreshold
Next
From: Tom Lane
Date:
Subject: Re: PGStatement#setPrepareThreshold