Re: Name for new function

From: Date: Mon, 17 Jul 2000 17:19:07 +0000
Subject: Re: Name for new function
References: 1 2 3 4  Groups: php.dev 
Request: Send a blank email to php-dev+get-24805@lists.php.net to get a copy of this message
At 20:01 17-07-00, Derick Rethans wrote:
Hi, Zeev Suraski wrote: As I pointed out, I tend to think the same. This should be done in user-space, until there's 'true' support for sub-selects in MySQL. Subselects are on MySQL's TODO lists for several *years* now and I don't think it will be implemented soon. What's the problem (besides it actually belongs in the MySQL server part) with a self-contained extension (now called db_layer) which implements this function? It doesn't clutter up the MySQL part of the code, and it's easy maintainable.
That's true. There are two main reasons why I don't think it should be readily available as a C function, when it can be implemented in PHP with just 20% performance loss: - C code is more prone to errors, is harder to maintain and extend - Similar to what Kristian brought up - if the function is available, it encourages people to use it, often without realizing the performance implications (such sub-selects, C or PHP, are VERY slow). Once sub-selects are available (which would happen sooner or later, probably sooner than later, now that MySQL's well funded) you would still have to maintain this old, then-redundant code.
I still agree that the best thing to do is to write to code into the MySQL-server, but I never saw such a mess of code. :-)
The MySQL server code is one of the more impressive uses of C++ that I've seen to date; It's VERY complex, but once you understand the idea behind it, you understand how brilliant it is. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/

« previous php.dev (#24805) next »