Skip site navigation (1) Skip section navigation (2)

Re: patch for passing the cts

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: patch for passing the cts
Date: 2005-06-15 13:37:09
Message-ID: 42B02F05.7000209@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Dave Cramer wrote:

> What about making the output of the current query parser a little  more
> flexible, and putting some of the intelligence in the executor.
> 
> More specifically, the parser currently breaks things up into  fragments
> which are very easily re-assembled by the executor. Instead  use the
> strategy below

The parsing is protocol-specific (different handling of
multiple-statement queries is the main thing), and we only need the
extra parsing complexity when we are handling a {call} escape.

We need an escape parser anyway since the backend doesn't know anything
about the JDBC escapes, so we'll have two parse steps going on anyway
unless you want to integrate that, too, into the query executor.

I can't see an obvious clean way of integrating this with the call
escape handling without duplicating lots of code and entangling the
high-level statement code with the low-level protocol details. I'd
prefer to see the query rewriting for {call} all happen in one place in
a protocol-independent way, and ideally only for the case when {call} is
actually used.

I really don't have any spare time for working on this in any detail :(
 I'll swallow my objections if nothing better comes along, but I fear
that code turning into an unmaintainable mess.

-O

In response to

pgsql-jdbc by date

Next:From: Donny TjandraDate: 2005-06-15 19:13:42
Subject: Function not found with JDBC 8.0 driver and later
Previous:From: Dave CramerDate: 2005-06-15 10:45:04
Subject: Re: patch for passing the cts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group