Re: CVS JDBC driver will try to use server-side-prepare on - Mailing list pgsql-jdbc

Oliver Jowett wrote:
> On Fri, Aug 15, 2003 at 09:55:02AM -0700, Barry Lind wrote:
>
> Hi Barry,
>
> Thanks for the detailed response!
>
>
>>Yes and no.  The plan is to convert fully over to the new V3 protocol
>>which will better handle cases like this and a lot of other things.  So
>>yes the plan is to move fully to server side prepared statements, but
>>via a different mechanism.  And conversly the plan isn't to move the
>>current mechanism forward as it has many limitations (as you are finding
>>out).  One of the big reasons for the new functionality in the V3
>>protocol is to provide better support for these type of opperations
>>efficiently.
>>
>>However a workaround for this specific problem would be to only use
>>server side prepared statements in the current implementation for
>>executeQuery calls, not for executeUpdate or for plain execute.
>
>
> Unfortunately it's executeUpdate() where I benefit from server-side prepare..
>

I probably should have said '... for executeQuery and executeUpdate
calls, not for plain execute.'  I consider the purpose of executeQuery()
to execute SELECT statements, and executeUpdate() for INSERT, UPDATE,
and DELETE, and plain execute() for everything else.  Though technically
the spec doesn't limit things in this way, practically (given the return
types) it is implied IMHO.


>
>>>Should we only be doing PREPARE on queries that are known to be safe (e.g.
>>>single-statement SELECTs), or is it better to try to catch the errors and
>>>abandon the prepare? (more general, but sounds a bit hairy).
>>>
>>>The reason that this came up is I'm modifying the driver to allow
>>>server-side prepare to be toggled at the connection- and datasource- level.
>>>Patches for that to follow once I've sorted this problem out.
>>>
>>
>>I would rather see you invest your time in implementing the V3 protocol
>>to do this correctly.  I am reluctant to commit patches along the lines
>>of what you are describing (check the archives for previous discussions
>>on this).
>
>
> I had a search in the archives .. nothing conclusive. There was:
>
>  http://archives.postgresql.org/pgsql-jdbc/2003-01/msg00012.php
>
> (and replies) where the main objection seemed to be to turning on
> server-side prepare *by default*. Did you have another thread in mind?
>

Yeah that was probably it.  Besides I think I restated my opinions in my
response to you, so there probably isn't anything else in the archives
that says much more.

> I'm not sure if we're ready to move our system to 7.4 & V3 at this stage.
> The JDBC driver seems somewhat less mature when it comes to the V3 protocol,
> and at the moment it seems like the additional development time needed to
> clean up the driver for V3 outweighs the benefits we'd get (for our app,
> anyway). I'm happy to be convinced otherwise, though.
>

I certainly can't tell you where it makes the most sense for you to
invest your time.  It is your time after all.  I can only voice my
opinions on where I would like people to invest their time for what I
believe to be the overall improvement of the driver.  But often what I
would like differs from the individual project priorities of developers,
which is fine and what open source is all about.  So go ahead and work
on this in the manner your project needs.  Given your recent patches, I
fully expect that no matter how you contribute your time, it will
greatly improve the driver.

thanks,
--Barry