Re: PGStatement#setPrepareThreshold
От | Bruce Momjian |
---|---|
Тема | Re: PGStatement#setPrepareThreshold |
Дата | |
Msg-id | 200608041615.k74GF2M16894@momjian.us обсуждение исходный текст |
Ответ на | Re: PGStatement#setPrepareThreshold (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: PGStatement#setPrepareThreshold
Re: PGStatement#setPrepareThreshold |
Список | 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 по дате отправления: