[Phpmyadmin-devel] BugFix question

Robin Johnson robbat2 at orbis-terrarum.net
Fri Nov 1 03:05:02 CET 2002


On Fri, Nov 01, 2002 at 09:28:36AM +0100, Rabus wrote:
> Hmm, my code would convert your "\n\r\n\r" into "\n\n\n"...
> But, where is a line feed style like "\n\r" used? I only know about
> these three ones:
> 
> Unix: "\n"
> Mac: "\r"
> Windows: "\r\n"
PalmPilot: "\n\r"

Yes, I was sitting at a café downtown, drinking coffee, and testing out
phpMyAdmin on my PalmPilot. Using Blazer as the web browser.
Wireless rocks! (I just bought wireless 3 days ago, second hand off
somebody, and i've had my Handspring Visor Edge for about a month now).

> As I tested my code about the ANSI style comment variation, I noticed
> that your code in line 243 got problems with my Windows line feeds...
> 
> $pos  = $GLOBALS['PMA_strpos']($sql, "\n", $count2);
> 
> imho, it would be annoying to handle all types of line feeds whenever we
> look for one.
> This is why I added these two lines at the beginning of the function.
Ok, for that bit we need it. However removing the \n or \r anything
inside a string is expressly out. I actually have databases where I want
that data preserved properly. So the only remaining solution is to write
a little function that imitates strpos looking for a line end character.

> Test your parser on a Windows or Mac client. You will see, without my
> code, it behaves a little different since it expects only Unix line
> feeds.
Windows is normally my main test platform. I don't have a mac at home.

> > @@ -227,7 +231,7 @@ if (!defined('PMA_SQP_LIB_INCLUDED')) {
> >              // ANSI style --
> >              if (($c == '#')
> >                  || (($count2 + 1 < $len) && ($c == '/') && 
> > ($sql[$count2 + 1] == '*'))
> > -                || (($count2 + 2 < $len) && ($c == '-') && 
> > ($sql[$count2 + 1] == '-') && ($sql[$count2 + 2] == ' '))) {
> > +                || (($count2 + 2 < $len) && ($c == '-') && 
> > + ($sql[$count2 + 1] == '-') && ereg("(\n|[space])", 
> > $sql[$count2 + 2]))) {
> >                  $count2++;
> >                  $pos  = 0;
> >                  $type = 'bad';
> > 
> > Intend that it could match broken ANSI comments of '--\n' in 
> > addition to the standard '-- '. Should we support this as it 
> > is partially supported by MySQL? I say partially, because the 
> > MySQL commandline client strips out anything matching 
> > '--.*\n', but the actualy MySQL server if it is sent raw 
> > commands throws a syntax error on '--\n'.
> 
> I does NOT! I tested it myself here and MySQL server treated "--\n" like
> a comment.
> I tested this behavior on MySQL 3.23.51 (Linux x86) and 4.0.4-beta
> (WindowsNT)
How did you test it?
a raw mysql query, or using phpMyAdmin?
I used a raw mysql query in PHP, and got this error:
You have an error in your SQL syntax near '; --
 SELECT 1' at line 1

Test code:
<?php
$con = mysql_connect('localhost','test','testing');
$res = mysql_query("SELECT 2; --\n SELECT 1;");
echo "E: ".mysql_errno()." ".mysql_error(). "\n";
?>

> Sorry for touching your holy parser code ;-)
LOL.
It was something that I was allowed to work on while I was getting paid,
my boss said sure, go and work on it, he didn't mind contributing back
to Open Source.
I'm busy researching more stuff myself.
What I called parser originally, is actually a tokenizer.
I'm trying to find a more efficent way to design it now.
Unfortunetly, Donald Knuth is only due to write about tokenizers in
2010, and I haven't found many texts on it at all.
For what it should do, my tokenizer is hideously slow. I was playing
with debug code in MySQL, and found that for the whole MySQL server to
tokenizer and analyze the query, it's approx 48x faster than my system on large
queries, and about 8x faster on small queries.

It looks like they have some really good ideas for doing it fast in
there, so I'm doing to see what I can get out of it in the next month or
two.

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20021101/6a3cec56/attachment.sig>


More information about the Developers mailing list