Am 11.04.2012 04:58, schrieb Darren Duncan: > Tim Bunce wrote: >> With regard to migrating SQL::Statement to be built on SQL::Translator, >> that's clearly a big task, but one that I presume could be broken down >> into smaller tasks. > > I think that it might work better to treat SQL like a general purpose > programming language, as much as is possible, rather than something > inordinately special, and then use that as a starting point from which > to design and build a parser for it. > > For example, think of your "create table" et al like a data type > definition (columns are attributes, constraints are constraints, etc) > plus variable declaration, and think of your "select" etc like a value > expression, and so on; stored procedures etc are routine definitions; > bind parameters are parameters.
Which would result in another module like current SQL::Parser. I want (and this is a primary goal of the rewrite target) not a strong coupled sql parsing engine - I want a intermediate data structure resulting from parse process which needs to be compiled into execution commands. The usage of the command pattern worked very well in where clause optimization - reduces complexity and improves performance. That's why I expect more similar improvements when doing it for the whole SQL::Statement processing engine. > Perhaps something like PPI might be a better starting point (this is a > stab in the dark) as it is designed for a full language. SQL::Translator has (or should have) the infrastructure for this. > That's what I would do if I were making a SQL parser. Oh wait, I am! Just another SQL Parser? Why not taking/improving one of the existing ones? Or is it, because they're not invented "here"? /Jens
