On Jan 16, 2008 12:18 PM, Stefan Nagtegaal <<a href="mailto:development@robuustdesign.nl">development@robuustdesign.nl</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm sorry to chime in on this topic which absolutely abracadabra for<br>me. I have absolutely no sense about databases at all, but a consenses<br>could be to:<br>- make drupal 6 pgSQL and MySQL compatible and release the bastard;
<br>- at the same day we make a poll on <a href="http://drupal.org" target="_blank">drupal.org</a> asking people what<br>database type they use, and open up comments for those that choose<br>pgSQL to tell us, why they do;
<br><br>That way we know:<br>- how much people are actually using pgSQL;<br>- and why they do it;<br></blockquote><div><br>Michelle already pointed to an existing poll that shows how many pgSQL users<br>there are. <br><br>
Here it is <a href="http://groups.drupal.org/node/6164">http://groups.drupal.org/node/6164</a><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Just some thought of someone who doesn't know anything about the<br>differences between MySQL and pgSQL. I personally never used the<br>latter...<br><br><br>Stefan<br><br><br>Op 16 jan 2008, om 18:05 heeft Konstantin Käfer het volgende geschreven:
<br><div><div></div><div class="Wj3C7c"><br>> Hi,<br>><br>> Please note that with my mail, I did not imply that we should go<br>> with the option "rip out postgres support". It as merely one of the<br>
> ways I can see, because we can certainly afford to keep the status<br>> quo. I am actually more interested in the second approach. Read <a href="http://en.wikipedia.org/wiki/Object-relational_mapping" target="_blank">
http://en.wikipedia.org/wiki/Object-relational_mapping</a><br>> as an introduction.http://propel.phpdb.org/trac/ is a nice ORM<br>> framework for this.<br>><br>> In case we don't want to go with a full blown ORM system, propel's
<br>> underlying DBAL is also worth a shot:<a href="http://creole.phpdb.org/trac/" target="_blank">http://creole.phpdb.org/trac/</a><br>> I'm not saying that we should ship with Creole (even though I don't<br>
> think that's necessarily a bad thing), but that we can look at how<br>> others solved this issue.<br>><br>> Konstantin Käfer -- <a href="http://kkaefer.com/" target="_blank">http://kkaefer.com/</a><br>>
<br>><br>> ------------------------------------------------------<br>> Don't miss DrupalCON Boston 2008 · March 3-6, 2008<br>> Learn more at <a href="http://boston2008.drupalcon.org" target="_blank">http://boston2008.drupalcon.org
</a><br>> Affordable sponsorship packages available<br>> ------------------------------------------------------<br>><br>> On 15.01.2008, at 20:14, Konstantin Käfer wrote:<br>><br>>> Hi,<br>>><br>
>> I am with Károly on this one. PostgreSQL support is certainly a<br>>> nice to have feature, but since there is noone seriously using it<br>>> (NowPublic used PostgreSQL a couple of months ago but eventually
<br>>> switched to MySQL), supporting it is more a hinderance than an<br>>> actual benefit for Drupal.<br>>><br>>> Fact is that MySQL is by far the most used DBMS used with Drupal.<br>>> That has two reasons: MySQL is installed on most hosts and most
<br>>> people in the PHP hosting business are familiar with setting up,<br>>> configuring and tuning MySQL.<br>>><br>>> The second reason is that most contrib modules don't properly<br>>> support Postgres, and only few people are running a Drupal site
<br>>> without several contrib modules. So, what buys us supporting<br>>> Postgres in core if you can't actually use it because critical<br>>> contrib modules don't support it properly? You guessed it. Let's
<br>>> not get into the illusion that module maintainers will eventually<br>>> add Postgres support; most of them don't even have Postgres<br>>> installed and I bet most are not willing to learn yet another DBMS'
<br>>> innards to circumnavigate all the cliffs associated with that task.<br>>><br>>> IMO, there are two ways we could go:<br>>><br>>> - Rip out Postgres support (but let's not drop the DBAL; we need it
<br>>> for mysql vs. mysqli and it's not really a speed issue)<br>>> - Completely abstract access to the database so that module authors<br>>> don't have to write actual SQL code<br>>><br>>>
<br>>> Konstantin Käfer -- <a href="http://kkaefer.com/" target="_blank">http://kkaefer.com/</a><br>>><br>>><br>>> ------------------------------------------------------<br>>> Don't miss DrupalCON Boston 2008 · March 3-6, 2008
<br>>> Learn more at <a href="http://boston2008.drupalcon.org" target="_blank">http://boston2008.drupalcon.org</a><br>>> Affordable sponsorship packages available<br>>> ------------------------------------------------------
<br>>><br>>> On 15.01.2008, at 19:22, Karoly Negyesi wrote:<br>>><br>>>> Hi,<br>>>><br>>>> Still there are no testers. I want to reiterate my plea: make<br>>>> postgresql support somewhat optional. If there are testers, great,
<br>>>> if<br>>>> not, go on with life. You can flame me, but this is already the<br>>>> state<br>>>> of affairs just noone wants to admit. Just see<br>>>> <a href="http://groups.drupal.org/node/6980" target="_blank">
http://groups.drupal.org/node/6980</a> . Greg spoonfeeds you. I know we<br>>>> will get testers for the rest of the week because of this letter and<br>>>> then they will move away as it happened uncounted times.
<br>>>><br>>>> I wonder what people will say. "Monoculture is bad" -- tick, do not<br>>>> bother with this answer. "You are evil" -- tick, do not bother<br>>>> either.
<br>>>> "There are testers, but" -- surely there are just they have hidden<br>>>> themselves really well. What about answering something<br>>>> constructive? I<br>>>> *am* bored by needing this raised every month.
<br>>>><br>>>> Regards<br>>>><br>>>> Karoly Negyesi<br>>><br>><br><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">
2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.