Re: JDBC, prepared queries, and partitioning - Mailing list pgsql-jdbc

From Simon Riggs
Subject Re: JDBC, prepared queries, and partitioning
Date
Msg-id 1202990876.16770.635.camel@ebony.site
Whole thread Raw
In response to Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc
On Fri, 2008-02-15 at 00:28 +1300, Oliver Jowett wrote:
> Simon Riggs wrote:
> > On Thu, 2008-02-14 at 20:18 +1300, Oliver Jowett wrote:
> >> Simon Riggs wrote:
> >>
> >>> But V3 supports having no parameters at all right?
> >> Yes, but you're missing the point. If you want to, for example, ask for
> >> metadata about the 4th parameter to the query, there has to *be* a 4th
> >> parameter. If you fold everything inline, you lose the various
> >> advantages that having the parameters out of line give you, such as the
> >> ability to query the server about their characteristics or stream their
> >> actual values in a binary form separate to the query, etc.
> >
> > Right now, people are choosing to use V2 because of the
> > parameter-folding characteristics. Those people are giving up the things
> > you mention, plus much much more. I'm suggesting that we make the
> > parameter folding an option, to allow people to choose. If they need
> > access to parameter metadata (or other possibilities) then they won't
> > take advantage of the parameter-folding option.
> >
> > I suggest we put the parameter folding option in now, then in 8.4 keep
> > the option but make it work via a GUC as Tom suggests.
>
> To do this in the driver basically needs a separate protocol path. The
> infrastructure is there for that, but it's not trivial to implement. You
> could use the existing v3 code as a basis, but there would be a lot of
> changes necessary as all of the current v3 code assumes it is working
> with parameterized queries at the protocol level.
>
> Does someone who is affected by this want to pick up this approach and
> send through some patches?
>
> I'm a bit nervous about introducing another protocol path since we have
> enough trouble trying to maintain the existing ones..

Seems heavy way of doing it.

Why not just fold in parameters if option is set and can continue to use
normal V3 route, just with zero parameters? Any JDBC calls that want to
inspect parameters can throw an exception when the option is set. So
JDBC thinks there were parameters, yet Postgres server thinks there were
no parameters.

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


pgsql-jdbc by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: JDBC, prepared queries, and partitioning
Next
From: Tomisław Kityński
Date:
Subject: SMALLINT vs short or... int?