On lun, 2008-01-21 at 13:02 -0500, Khalid Baheyeldin wrote:
That is all good, but how is that related to the issue at hand? We have a problem as it is with development and testing resources for PostgreSQL, so your solution is to make everyone use PostgreSQL instead of MySQL to solve that problem?
I am not arguying that you should drop MySQL support. Not everyone should use PostgreSQL, only Drupal main hackers. Users will certainly continue to use MySQL. I am only arguying that if you were developing Drupal on PostgreSQL, it would solve the portability issue. This is not a joke. Same goes for translation. Let's suppose that you are writing a book in an old 500 year BC language, written in stange glyphs. Okay? You will have to translate the book into English and then translate the English book into other languages. Non-standand source => English => Other languages. Now, suppose that you write the same book directly in English. You can translate it to all languages. English is probably the easiest language in the world. Sames goes for SQL99, it is easy and very pure. You can nearly smoothly run ANY SQL99 syntax in MySQL. But the converse is not true. DB2 and Oracle are completely SQL 99 compliant. If you run a PostgreSQL syntax under DB2 and Oracle, it goes like a charm. To recall the story of the book : Write a standard SQL99 => Run everywhere on all other databases including MySQL. Thus, we can safely assume that if you were using the SQL99 standard implementation (namely PostgreSQL), it would solve your portability issues. Last example, look at your database types. I don't remember how many database types you are using in the abstraction layer. In SQL99, there are not that many types. From memory, I recall int4, int8, boolean (or bit), monetary, blob (texte), etc ... Focusing on this small list of types makes it easier to port to other database systems. Same for everything else. Kind regards, Jean-Michel