Re: PGStatement#setPrepareThreshold
От | Dave Cramer |
---|---|
Тема | Re: PGStatement#setPrepareThreshold |
Дата | |
Msg-id | 907E63BE-BC8C-45C9-9FFD-E0F1B1F775B4@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: PGStatement#setPrepareThreshold (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: PGStatement#setPrepareThreshold
|
Список | pgsql-jdbc |
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. > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
В списке pgsql-jdbc по дате отправления: