I think the root of the problem is that MySQL lacks separation of concerns: the same parse tree is used at every stage of query processing. On the other hand, in Postgres, a parse tree is represented by a Query structure (a tree of C structures), the query optimizer generates and considers a bunch of throwaway Path tree structures, then the query planner generates a tree of Plan nodes (Plan tree). The query execution is a state machine; Init...(_) functions generate various PlannerInfo structures/nodes, which are ultimately responsible for runtime query execution. In the Postgres world, only Query tree and Plan tree need to be copyable and serializable. This makes everything simpler.
Regards, Alex Esterkin On Mon, May 4, 2009 at 1:05 PM, Brian Aker <[email protected]> wrote: > Hi! > > On May 4, 2009, at 9:22 AM, Jim Starkey wrote: > > that uses parameters, reducing the threat of SQL insertion. I don't >> think, however, that it is feasible as a plugin. >> > > The big issue here is having some sort of parse tree that is > serialize'able. Once you have that it is a matter of some protocol plugin > being able to push a piece of execution into the "right" point in the stack. > > Refactoring ITEM into something which is useable/revisionable/etc... seems > to be the key. > > Cheers, > -Brian > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
