On Thu, 25 Jul 2002, Lo�c wrote:

Your parser is a great job :)

Thanks. I tried to test it out as throughly as possible.

Marc just submitted for me some changes in your files. They are just related to coding standard problem except a "foreach" I replaced by a while for PHP3 compatibility.

Ok.

At the beginning of "sqlparser.lib.php3" there is a constant I renamed from "DEBUGTIMING" to "DEBUG_TIMING" but I can't find where it is defined. I you can change it...

DEBUG_TIMING and the strange order of function declaraction inside that block is related to my testing harness for the SQL Parser. I'm going to keep the testing harness and those calls there for the moment, while the analyzer and tweaking the Parser is in progress, and probably remove it around 2.3.2 or 2.3.3 once everything has totally stabilized out.

Now let's talk about PHP3 compliance problem in "sqlparser.lib.php3":

1. I suggest to replace lines 168-170 by $pos = strpos(' ' . $sql, $quotetype, $oldpos) - 1; if ($pos < 0) { Could you check if it works this way?

No. This does NOT work, as we already start at $oldpos instead of zero. Instead, this works: $pos = strpos(' ' . $sql, $quotetype, $oldpos + 1) - 1; if ($pos < 0) {

Merged in CVS.

It seems this is the only strpos call where we should do different things depending on "not found" and "found at the begenning of the string". Am I right?

Presently yes, but I never did complete all of the error detection functions.

2. "trigger_error" is a PHP4 function. Couldn't we use "PMA_mysqlDie()" instead?

This is a problem actually. I don't want to terminate the running of the page just because my SQL Parser can't handle something in the query. I wanted to just print out a message as to why my parser failed and continue execution of the page contents. triggering an error with NOTICE level so that it just prints a message seemed suitable at the time, but I think we might want to convert to just having a global variable with an error message for the parser subsystem. Like I said, I never completed the query error detection at all.

3. "print_r" is also a PHP4 function. I suggest to display the array "manually".

I was actually just dumping the contents of the analyzer data while I was working on it. In the end, that function won't be printing any data at all, but returning it instead.

I've changed that to just return the array for now, and I'll print it out from my test harness instead.

Merged in CVS.

4. "gzcompress" and "gzcompress" can't be used with PHP3 and must be tested before use in PHP4 ie if (function_exists('gzcompress'))....

I wanted a method in which I could get a specific data dump from a user containing all the information I needed to fix the SQL Parser.

Just dumping the data base64 encoded got really big, so I was just running it thru gzcompress before doing the base64 encoding.

Any ideas how I could still shrink the size for the bug posting ?

Considering this, I actually had a major idea. The linux kernel has a 'BUG()' call. For some of our PMA code, a similar thing would actually be a very useful function call.

Ideally it would print out a human readable message about the bug first of all, probably in the current language, then a gzip+base64 data chunk, with instructions to post the chunk on the Bug tracker (maybe even a 'post' link that partly auto-fills the form ?).

The data chunk can contain whatever we will need in each case. In my existing use of it, I have a CVS $Id$ tag included for version tracing.