On 26 Apr 2009, at 12:55, Konstantin Osipov wrote:
> 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.
That was done quite a while ago - the intent is to preserve the
existing functionality but to encapsulate without duplicating code. On
hindsight, perhaps I was too aggressive in avoiding code duplication
as it resulted in a somewhat contrived design.
>
> What does class RestoreProtocol do?
Simple/stupid utility class to restore values of thd->text/binary
protocol. Used in earlier implementations but with later experimental
refactorings which resulted in everything returning data in a
select_result class, it's requirement has become somewhat unnecessary.
>
> 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 ;).
Ok, I must admit that I haven't bothered to examine the 6.0 tree since
last year and I briefly look at changes in 5.1 only when it obstructs
merges.
I will look at doing a proper refresh soon - but just keep in mind
that I can only spare my personal time.
>
> Please do write any questions you come up with here, on this list.
Thanks. I am glad that this is eventually being examined.
>
> 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.
Admittedly, I only implemented table functions because it was easily
obtainable with relatively little code.
I will hope to see progress soon then.
Regards,
Antony.
>
>
> --
> kostja
