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
