[development] So why we do support postgresql?

Konstantin Käfer kkaefer at gmail.com
Wed Jan 16 17:05:46 UTC 2008


Hi,

Please note that with my mail, I did not imply that we should go with  
the option "rip out postgres support". It as merely one of the ways I  
can see, because we can certainly afford to keep the status quo. I am  
actually more interested in the second approach. Read http://en.wikipedia.org/wiki/Object-relational_mapping 
  as an introduction.http://propel.phpdb.org/trac/ is a nice ORM  
framework for this.

In case we don't want to go with a full blown ORM system, propel's  
underlying DBAL is also worth a shot:http://creole.phpdb.org/trac/ I'm  
not saying that we should ship with Creole (even though I don't think  
that's necessarily a bad thing), but that we can look at how others  
solved this issue.

Konstantin Käfer -- http://kkaefer.com/


------------------------------------------------------
Don't miss DrupalCON Boston 2008 · March 3-6, 2008
Learn more at http://boston2008.drupalcon.org
Affordable sponsorship packages available
------------------------------------------------------

On 15.01.2008, at 20:14, Konstantin Käfer wrote:

> Hi,
>
> I am with Károly on this one. PostgreSQL support is certainly a nice  
> to have feature, but since there is noone seriously using it  
> (NowPublic used PostgreSQL a couple of months ago but eventually  
> switched to MySQL), supporting it is more a hinderance than an  
> actual benefit for Drupal.
>
> Fact is that MySQL is by far the most used DBMS used with Drupal.  
> That has two reasons: MySQL is installed on most hosts and most  
> people in the PHP hosting business are familiar with setting up,  
> configuring and tuning MySQL.
>
> The second reason is that most contrib modules don't properly  
> support Postgres, and only few people are running a Drupal site  
> without several contrib modules. So, what buys us supporting  
> Postgres in core if you can't actually use it because critical  
> contrib modules don't support it properly? You guessed it. Let's not  
> get into the illusion that module maintainers will eventually add  
> Postgres support; most of them don't even have Postgres installed  
> and I bet most are not willing to learn yet another DBMS' innards to  
> circumnavigate all the cliffs associated with that task.
>
> IMO, there are two ways we could go:
>
> - Rip out Postgres support (but let's not drop the DBAL; we need it  
> for mysql vs. mysqli and it's not really a speed issue)
> - Completely abstract access to the database so that module authors  
> don't have to write actual SQL code
>
>
> Konstantin Käfer -- http://kkaefer.com/
>
>
> ------------------------------------------------------
> Don't miss DrupalCON Boston 2008 · March 3-6, 2008
> Learn more at http://boston2008.drupalcon.org
> Affordable sponsorship packages available
> ------------------------------------------------------
>
> On 15.01.2008, at 19:22, Karoly Negyesi wrote:
>
>> Hi,
>>
>> Still there are no testers. I want to reiterate my plea: make
>> postgresql support somewhat optional. If there are testers, great, if
>> not, go on with life. You can flame me, but this is already the state
>> of affairs just noone wants to admit. Just see
>> http://groups.drupal.org/node/6980 . Greg spoonfeeds you. I know we
>> will get testers for the rest of the week because of this letter and
>> then they will move away as it happened uncounted times.
>>
>> I wonder what people will say. "Monoculture is bad" -- tick, do not
>> bother with this answer. "You are evil" -- tick, do not bother  
>> either.
>> "There are testers, but" -- surely there are just they have hidden
>> themselves really well. What about answering something  
>> constructive? I
>> *am* bored by needing this raised every month.
>>
>> Regards
>>
>> Karoly Negyesi
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2110 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20080116/39f9e78a/attachment.bin 


More information about the development mailing list