On 10 Jun 2006, at 4:03 PM, Moshe Weitzman wrote:
creation. At best it will be lowest common denominator, and performance cannot be achieved without tweaking to the specific database.
please, we are only talking about schema definitions. performance is a non issue. Not necessarily.
Different databases could still have different optimal index configurations. This code is meant to cover the 95% of cases, however. And there's nothing stopping us from still using if ($db_type['mysql']) { // some mysql specific alterations / optimisations } It's not a way to stop people from having to learn sql. SQL is still a pre-requisite for developing with Drupal. It is only meant to save the developer from having to know 2 or 5 different variants of sql just to fully support our feature set. It is still almost exactly like sql, it's just broken up into a more readily accessible data structure for us to work with it. When it comes down to it, the code is in all practicality like theme () functions for sql statements. Switching to different output based on db_type, not different selected theme. I am also ok with using the sql parser found here (http://cvs.sf.net/ viewcvs.py/easymod/sql_parser/root/includes/sql/) since the end result is the same. Whether Dries wants to admit it or not, the current inequality of postgres and mysql support is a maintenance nightmare. Now that automated installs are happening, the demands of keeping the code in synch are only going to grow, and the problems from failing to do so, will become more apparent. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com