Hi List,
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.
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.
The main parser function is ready for merging in the source tree, apart from needing to be re-indented to match the rest of the code in PMA. On that note, could somebody make some suggestions as to settings for VIM to indent the sourcecode like we want it.
I'm just tidying up the code of the extractor and the pretty-printer, and once those are all ready, they will be integrated into the source tree all at once. The entirety of my code is running ~900 lines at the moment, so I will put it into a new file, lib/parser.inc.php3.
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.
I'll do my best to have it ready by Sunday, but I probably won't manage.
----- Original Message ----- From: "Robin Johnson" robbat2@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.
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!
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
btw, I'm going to be away for vacation from July 20th till August 3rd and from August 23rd till August 25th.
Regards,
Alexander
On Thu, 11 Jul 2002, Rabus wrote:
----- Original Message ----- From: "Robin Johnson" robbat2@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.
Hi,
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.
I think it's more linked to the following behaviour :
mysql> SELECT- 20; +------+ | - 20 | +------+ | -20 | +------+ 1 row in set (0.00 sec)
mysql> SELECT+ 20; ERROR 1064: You have an error in your SQL syntax near '+ 20' at line 1 mysql> SELECT + 20; ERROR 1064: You have an error in your SQL syntax near '+ 20' at line 1 mysql> SELECT - 20; +------+ | - 20 | +------+ | -20 | +------+ 1 row in set (0.00 sec)
mysql> SELECT -20; +-----+ | -20 | +-----+ | -20 | +-----+ 1 row in set (0.00 sec)
mysql> SELECT +20; +-----+ | +20 | +-----+ | 20 | +-----+ 1 row in set (0.00 sec)
(the - is oddly treated here)
Regards, Jocelyn
Rabus wrote:
----- Original Message ----- From: "Robin Johnson" robbat2@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.
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!
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
btw, I'm going to be away for vacation from July 20th till August 3rd and from August 23rd till August 25th.
Regards,
Alexander
This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
This schedule revision is OK for me too. However I would not like to see a -RC5, people will get tired of installing our RCs :)
Should we publish the schedule on phpMyAdmin.net?
Marc
-
Jocelyn Fournier -
Marc Delisle -
Rabus -
Robin Johnson