Re: JDBC, prepared queries, and partitioning

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