[development] Do not let postgresql hold back great patches

[Larry Garfield]

On Mon, 12 Nov 2007 08:29:34 -0500, Earnie Boyd <earnie at users.sourceforge.net> wrote:

>> Amen brother. I am happy which simply removes LOWER from those
>> queries and kicks the ball to the postgresql half of the playground.
>> As I stated on my blog I have nothing against posgresql just I do not
>> want to deal / held back with it. Any support for this solution?
>>
>
> IMO, we need to focus on Drupal SQL[1] and not MySql SQL or Postgresql
> SQL or Oracle SQL for coding purposes.  Another layer of abstraction
> handles the nitty gritty of each different DB.  AFAIR, the code prior
> to 6 was both MySql and PgSql friendly.  So making a change in a
> different direction for Drupal 6 doesn't seem TRT to me.  However if
> Drupal 5 wasn't as PgSql friendly as I remember then I agree with
> Karoly.  For Drupal 7 I would like to see Drupal SQL handle all of the
> syntax changes needed for various DB engines; that means no more
> testing of $db_type outside of the Drupal SQL abstraction.  Then a
> company with Oracle, Sybase and DB2 could display data from all three
> database types comfortably with Drupal.
>
> [1] http://drupal.org/node/191486

You have just proposed that we create our own serialized language called DSQL that we then regex for *every single query* and then rewrite a query for each database backend according to some abstract set of rules.

No.

That is way too complex and way too slow, especially when it would involve slowing down MySQL (95%) users purely for the sake of everyone else (5% at most).  It is also a sign that the architecture is bad: If you serialize a data structure and then string-parse the serialized version, you are doing something wrong.  You should have parsed it first, then serialized.

The only alternative I see is to use data-structure-based query builders instead in some cases.  We do that now for DDL statements (Schema API).  I'm planning to do that for all insert/update/delete statements in Drupal 7, and I'm pondering how feasible it would be to require certain types of SELECT queries to use one.  I'm still undecided.

That is, however, beside the point for right now.  Right now, the point is that we're holding back a performance improvement under MySQL and a way to increase the number of shared hosts Drupal runs on (those that don't allow temp tables) for the sake of PostgreSQL, which few shared hosts support anyway.

While I agree that forcing us to think about multiple databases is good architecturally, we just don't have the resources to support non-MySQL as well as we do PostgreSQL.  I would not object to committing the MySQL portions and fixing PostgreSQL later.

--Larry Garfield