Re: PGStatement#setPrepareThreshold - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: PGStatement#setPrepareThreshold
Date
Msg-id 907E63BE-BC8C-45C9-9FFD-E0F1B1F775B4@fastcrypt.com
Whole thread Raw
In response to Re: PGStatement#setPrepareThreshold  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PGStatement#setPrepareThreshold  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PGStatement#setPrepareThreshold
Next
From: Bruce Momjian
Date:
Subject: Re: PGStatement#setPrepareThreshold