[Phpmyadmin-devel] Re: SQL Parser

[Robin Johnson]

On Thu, 11 Jul 2002, Rabus wrote:

> ----- Original Message -----
> From: "Robin Johnson" <robbat2 at fermi.orbis-terrarum.net>
> > I've got my SQL parser 100% now given the information that I have.
> > It's ~10% slower than the speeds I posted before, but I think those are
> > fast speeds still. Just in case somebody wants to put in a huge chunk of
> > SQL in one of the SQL input boxes, and they don't really care about my
> > parser seeing it, I think we should add a checkbox for them to bypass it
> > if they want to. I see this as being really important if they are using
> > the SQL upload box to run a really large SQL query, so maybe we even
> > disable it automatically if they put in a query larger than a certain
> > size. I'd say possibly all queries larger than 2k should not be parsed, as
> > the odds say that the query is being pasted in from somewhere else.
>
> I think that PMA currently doesn't display the queries if a user submit more
> than 15 ones, am I right?
> imho this is a good solution and we should keep it for the parser behavior
> as well.
You cannot ever get an accurate count of the number of queries without
using the the parser!

This is because given the current state of string handling, I could do
something similar to this:
INSERT INTO foo values (';;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;');
SELECT * FROM foo;

That is only two queries, and it would fail under the current test to see
the number of queries.

That is why I said we should get on the size of the input.

> > The funniest thing that, is I have now found two bugs in the parser
> > mechanism of MySQL, and submitted bug reports for them. I haven't seen any
> > reply yet tho.
> Cool, show me!

1.
Look at the result of this query (the error that happens)
SELECT + /* foo */ 20;
Now compare it with this:
SELECT - /* foo */ 20;
the second one should give an error as well, but it doesn't.

2.
Using PMA, Create a table with two columns named 0xffg and 0xgff.
Insert a line of data. (any datatypes are fine).

Now do
SELECT * FROM table;
compare to:
SELECT 0xffg,0xgff FROM TABLE:

The 0xffg column is messed up by a unicode evalution in MySQL.
0xffg is in actuallity a totally valid column/table identifier, just like
0xgff.

> > I've been invited on a short vacation on the 12th and 13th of this month,
> > so I don't know if I will have the extractor ready for our -rc3 point on
> > Sunday.
> We submitted a lot of important bugfixes since RC2 so we shouldn't wait with
> the release of RC3 anymore.
> But we do need your new parser and it needs to be tested before the release.
> Furthermore, there are still some bugs to fix, so I'd suggest the following
> new schedule:
> RC3: July 14th
> RC4: July 28th
> FINAL: August 11th
I approve of this timeline as well.
Lets release RC3 without my parser enabled yet, but start to have it
included in the code. That we we get two weeks of testing it in the CVS,
and two weeks of RC level testing for it.

I also have a non-intrusive feature that I wish to integrate, that will
make larges waves in the SQL world. I'll speak about it in my next email
that I sent a bit later today. Its about an SQL Validator found on
http://developer.mimer.com/validator/ that is about to be accesible via
SOAP and XML freely.

> btw, I'm going to be away for vacation from July 20th till August 3rd and
> from August 23rd till August 25th.
I'm going to be away July 24th -> July 30th or there abouts as well.

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639