[rt.cpan.org #69573] Multiple joins not supported?

<URL: https://rt.cpan.org/Ticket/Display.html?id=69573 >

On Tue Oct 02 11:58:41 2012, BBYRD wrote:
> On Tue Oct 02 10:56:09 2012, REHSACK wrote:
> > I put it into this because of it's all the same reason. Hope it's gonna
> > fixed when rewriting SQL::Statement.
> 
> Believe it or not, I am actively developing in this area, and have been
> for the last couple of months.

I believe that. That was not a comment to your effort nor your skills -
it was a comment on the quality of the patch. At first it didn't apply
cleanly and second it leads "make test" to fail.

Because I know that you active developing, I didn't simply reply
"patched with modifications" - I told you it costs me a lot extra effort
and hope your next submissions will be better.

> Latest DFS levels:
> 
> 1. SQL::Statement needs a new parser.  Parser should be something like
> SQLT, with multiple in/out parsers.

Yes, we all agree on it. I talked to mst and ribasushi about that and I
think we found a solution from several kind of views. When ribasushi is
back from USA we meet again and talk about some details.

> 2. SQLT currently does not work with non-schema statements, so a new
> parser project should be created.  Parser should borrow from a real,
> active RDBMS like PostgreSQL.

Additional ones might be - but the one being bundled with SQL::Statement
will definitively not. But the design we discussed at YAPC::EU should
allow you to write as many parsers supporting as many dialects as your
projects require. This was a major goal I wanted to reach (because I
understood your requirements - I just disagree fulfilling them in the
SQL::Parser).

> 3. Pg's parser is written in Bison/C.  Need to convert to Perl.
> 
> 4. Successfully converted to Eyapp, but Eyapp is pretty outdated and
> inefficient as a parser language.  Queries still slow.  Would have more
> success with a modern top-down parser like Pegex.

I'm always open for suggestions. Pegex looks interesting, thanks for the
suggestion.

But to be true - a real good thing would be some kind of tool which is
able to generate Pure-Perl Parser code as well as optional XS support
without requiring additional modules at runtime.

> 5. Pegex is a rather new language and needs some feature enchantments to
> help support the conversion and provide a long-term code base for the
> parser.  Working with Ingy to shape language to work better with larger
> parsers like this.
> 
> Currently at level 5, which I think is about as far down the rabbit hole
> as you can go.  Have written a quick eyapp2pegex convertor, but like I
> said, some shaping of the language needs to happen first to keep things
> sane.

Let's see what future brings. A token based parser is the next primary
goal - this is the thing I agree on.

I'd prefer to have that kind of discussion on dbi-dev@ (with probably
ribasushi, frew and mst on CC - for Data::Query and SQLT parts of
discussion).