Hello Antony,
What's the idea with introducing class Transport?
I liked the fact that you remove all traces of the embedded
library from the non-embedded protocol (protocol.cc), but I
couldn't understand the need to introduce an additional level of
indirection with class Transport.
What does class RestoreProtocol do?
Could you take a look at the "execute direct" connection
implementation and class Protocol_local that is currently in 6.0
(sql_prepare.cc), could the patch be re-based to use it?
As far as I could understand, moving to Ed_connection would let
you avoid code duplication in sp_instr_external, which
currently has to copy all COM_ level commands and handle them,
as well as manually parse SQL, as well as re-implement the
most of the client-server protocol ;).
Please do write any questions you come up with here, on this list.
Thanks,
PS With "virtual tables/table functions" implementation in this
patch, which is based on MySQL 4.1 derived tables and hooks into
mysql_derived_filling(), I'm afraid it has to be put on hold.
The derived tables infrastructure that it relies on is gone in
6.0, and we are re-implementing derived tables as mergeable views.
It's a bit unpleasant to our users when EXPLAIN fills all derived
tables (or invokes all table functions) :).
The issue with the taken approach to derived tables is that it
is unaware of the optimizer cost analysis --
mysql_derived_filling() happens during semantical analysis of the
query, i.e. prematurely.
We do have a plan for virtual tables, but first we need to re-work
our handler (PSEA) interface to support cursors, as well
as rework our execution layer to use cursors instead of 'handler'
objects to work with tables. Once true PSEA level cursors are
in place, a table function can be a sub-class of class
Cursor. Timour is coordinating this work, while I'm doing the
re-engineering part with the handler. With regard to progress,
I have to admit that I'm stuck, since I haven't been able
to get a review for a patch that was ready in September 2008.
--
kostja
