On Mon, Mar 9, 2009 at 5:51 PM, Guillaume Cottenceau g...@mnc.ch wrote:
Until it's possible to specifically tell the JDBC driver (and/or
PG?) to not plan once for all runs (or is there something better
to think of?), or the whole thing would be more clever (off the
top of my head, PG could try
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this behalf.
No, 8.2 did it too (otherwise we wouldn't have considered 8.3.0
Tom Lane schrieb:
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this behalf.
No, 8.2 did it too (otherwise we wouldn't
On Mon, Mar 9, 2009 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this
The driver will use unnamed statements for all statements until it
sees the same statement N times where N is 5 I believe, after that it
uses a named statement.
Shame there's no syntax for it to pass the a table of the parameters to
the server when it creates the named statement as
1. And how do you do that from JDBC? There is no standard concept of
'unnamed' prepared statements in most database APIs, and if there were the
behavior would be db specific. Telling PG to plan after binding should be more
flexible than unnamed prepared statements - or at least more
On 3/9/09 1:40 PM, Oliver Jowett oli...@opencloud.com wrote:
Scott Carey wrote:
1. And how do you do that from JDBC? There is no standard concept of
I've suggested that as a protocol-level addition in the past, but it
would mean a new protocol version. The named vs. unnamed statement
