Re: feature request for SQL::Statement::Structure

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