[development] Do not let postgresql hold back great patches

[Chris Johnson]

On Nov 28, 2007 1:45 PM, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> On Wed, 28 Nov 2007 11:48:23 +0100
> "Chris Johnson" <cxjohnson at gmail.com> wrote:


> > Maybe there is an open-source tool which can validate standard SQL
> > which could be used.  Then our DB abstraction could require a
> > verifiable standard SQL syntax which would then be translated (where
> > necessary) into the MySQL, Oracle, Postgres, etc. equivalents.
> > This might only be for CRUD operations (data manipulation
> > statements) and not for DDL, for which we already have a reasonable
> > API and which are much less standardized.
>
> On the long run this doesn't give space for optimisations.
> People should write SQL with standards in mind and not MySQL in mind
> but the DB abstraction layer should leave a door open for
> optimisation.
> There should be a default path that doesn't impact on performances
> (including both mysql and pgsql code) that let module writers write
> custom code for a particular DB *if* they are willing to do so.


Well, actually I'm very much in favor of optimized SQL, because I'm
very much in favor of optimized Drupal.  I hate software bloat.

So what I really think -- and this is a truly unpopular position -- is
that most of the SQL should be written by "core" SQL coders, and the
rest of us should be accessing data through object abstractions, i.e.
get me a node, get me a user.   Underneath is the highly optimized,
shiney, sparkly, incredibly brilliant PHP and SQL code written by the
'database access guru core team'.

Ok, I'll put the crack pipe down now.

My goal with the above suggestion was just to make it easier for
people to write the standard SQL to MySQL || PGSQL || MS SQL || Oracle
abstraction-layer translation stuff by helping authors avoid difficult
to translate non-standard-isms.  If developers can avoid creating
modules which depend on unique special extension X in MySQL or special
extension Y in Postgres (unless they really meant to), then we'd be
better off in our question to support more than one database.

I suppose I have not made things much clearer.  For some reason, I'm
plagued with complicated phraseology today.  :-/