[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