Re: [development] So why we do support postgresql?
Something like http://groups.drupal.org/node/6164 ? Michelle On 1/15/2008 5:13:25 PM, Khalid Baheyeldin (kb@2bits.com) wrote:
I support chx's proposal, don't let PostgreSQL hinder the development cycle.
But, every time we have this discussion, we get people talking theories but no concrete data.
We here about Drupal must be database agnostic, down with monoculture, ... etc. Which is all good.
What we are missing is how many real world websites use Drupal AND PostgreSQL, how big these sites are, how many contributed modules are being used, ...etc.
I propose a poll with the following options on it:
- MySQL MyISAM - MySQL InnoDB - PostgreSQL - other
With comments enabled so we get at least some sampling of what is out there.
Some data is better than no data, so let us get it.
Yes, but with differentiation between InnoDB and MyISAM. It already says Drupal sites are 94% Drupal, with 3% Postgres (and one vote for MS SQL and Oracle). On Jan 15, 2008 6:25 PM, Michelle Cox <mcox@charter.net> wrote:
Something like http://groups.drupal.org/node/6164 ?
Michelle
On 1/15/2008 5:13:25 PM, Khalid Baheyeldin (kb@2bits.com) wrote:
I support chx's proposal, don't let PostgreSQL hinder the development cycle.
But, every time we have this discussion, we get people talking theories but no concrete data.
We here about Drupal must be database agnostic, down with monoculture, ... etc. Which is all good.
What we are missing is how many real world websites use Drupal AND PostgreSQL, how big these sites are, how many contributed modules are being used, ...etc.
I propose a poll with the following options on it:
- MySQL MyISAM - MySQL InnoDB - PostgreSQL - other
With comments enabled so we get at least some sampling of what is out there.
Some data is better than no data, so let us get it.
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can say nothing more than http://groups.drupal.org/node/6164#comment-18064 Regards, Edison Wong Michelle Cox wrote:
Something like http://groups.drupal.org/node/6164 ?
Michelle
On 1/15/2008 5:13:25 PM, Khalid Baheyeldin (kb@2bits.com) wrote:
I support chx's proposal, don't let PostgreSQL hinder the development cycle.
But, every time we have this discussion, we get people talking theories but no concrete data.
We here about Drupal must be database agnostic, down with monoculture, ... etc. Which is all good.
What we are missing is how many real world websites use Drupal AND PostgreSQL, how big these sites are, how many contributed modules are being used, ...etc.
I propose a poll with the following options on it:
- MySQL MyISAM - MySQL InnoDB - PostgreSQL - other
With comments enabled so we get at least some sampling of what is out there.
Some data is better than no data, so let us get it.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjWPdBPIQaq+ZRd8RApAkAKCqrFjyPuShd1yBFhkhxt4m7cQbbQCgvf+3 apZJsfUhNciMCCd2bzszGIA= =WSOE -----END PGP SIGNATURE-----
I have to applaud those who go out of their way to test on PostgreSQL. This is noble of you. I may start doing it at some point even ... (I did some benchmarks with a guy from the list helping, sorry forgot his name). But think of it: how scalable and sustainable is this? What about other databases? Will you do that for MS SQL (while running Mac/Linux?) Oracle?
"Khalid Baheyeldin" <kb@2bits.com> wrote:
I have to applaud those who go out of their way to test on PostgreSQL. This is noble of you.
I may start doing it at some point even ... (I did some benchmarks with a guy from the list helping, sorry forgot his name).
I believe that was me. I'm sorry I haven't had more time to help out, but the personal issues I thought would be resolved by now are still a work in progress.
But think of it: how scalable and sustainable is this? What about other databases? Will you do that for MS SQL (while running Mac/Linux?) Oracle?
The problem with this community is that it's oddly divided. Is Drupal going to be database agnostic or not? If the opinion of the community is that supporting multiple databases is worthwhile, then folks need to bite the bullet, accept that doing so is a _lot_ of work, and quit whining. The fellow who starts these threads every month or so needs to quit his damn whining and help out. His bitching is a constant distraction. And his excuse that he doesn't care about PostgreSQL is bull. If Karoly doesn't care about a particular Drupal module, should everyone else quit caring as well? If he doesn't want to support a less popular browser, like Firefox, should Drupal quit caring? Being database agnostic is not an easy goal. The weak of resolve need not apply as they'll fail anyway. But it seems to me that most of the Drupal developers are not going to be easily dissuaded. And why should they be? If Karoly convinced them to give up Postgres support, next he'd convince them to give up IE support, then he'd scare them away from some other challenge or another. Great projects don't get great by whining that "it's too hard" and backing down. As many have pointed out, it's not really about PostgreSQL ... it's about supporting multiple databases. If Drupal drops PostgreSQL support, the overall goal of supporting multiple databases will suffer. The approaches that folks are taking to abstract the database are the correct approaches, but they're not as easy as just giving up, and they'll take time. -- Bill Moran http://www.potentialtech.com
Bill you have stepped out of line. You are flaming a person you obviously know nothing about, please be so kind to look at http://drupal.org/user/9446 On 1/16/08, Bill Moran <wmoran@potentialtech.com> wrote:
"Khalid Baheyeldin" <kb@2bits.com> wrote:
I have to applaud those who go out of their way to test on PostgreSQL. This is noble of you.
I may start doing it at some point even ... (I did some benchmarks with a guy from the list helping, sorry forgot his name).
I believe that was me. I'm sorry I haven't had more time to help out, but the personal issues I thought would be resolved by now are still a work in progress.
But think of it: how scalable and sustainable is this? What about other databases? Will you do that for MS SQL (while running Mac/Linux?) Oracle?
The problem with this community is that it's oddly divided. Is Drupal going to be database agnostic or not? If the opinion of the community is that supporting multiple databases is worthwhile, then folks need to bite the bullet, accept that doing so is a _lot_ of work, and quit whining.
The fellow who starts these threads every month or so needs to quit his damn whining and help out. His bitching is a constant distraction. And his excuse that he doesn't care about PostgreSQL is bull. If Karoly doesn't care about a particular Drupal module, should everyone else quit caring as well? If he doesn't want to support a less popular browser, like Firefox, should Drupal quit caring?
Being database agnostic is not an easy goal. The weak of resolve need not apply as they'll fail anyway. But it seems to me that most of the Drupal developers are not going to be easily dissuaded.
And why should they be? If Karoly convinced them to give up Postgres support, next he'd convince them to give up IE support, then he'd scare them away from some other challenge or another. Great projects don't get great by whining that "it's too hard" and backing down.
As many have pointed out, it's not really about PostgreSQL ... it's about supporting multiple databases. If Drupal drops PostgreSQL support, the overall goal of supporting multiple databases will suffer. The approaches that folks are taking to abstract the database are the correct approaches, but they're not as easy as just giving up, and they'll take time.
-- Bill Moran http://www.potentialtech.com
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
"Oleg Terenchuk" <litwol@gmail.com> wrote:
Bill you have stepped out of line. You are flaming a person you obviously know nothing about, please be so kind to look at http://drupal.org/user/9446
My intent is not to "flame" anyone. The only thing I know about Karoly is that he comes on this list about every 30 days and starts whining about PostgreSQL. Looking at the page you directed me to, he has a lot of commits. That's great, does it make him immune to criticism? I apologize to the community for stepping out of line.
On 1/16/08, Bill Moran <wmoran@potentialtech.com> wrote:
"Khalid Baheyeldin" <kb@2bits.com> wrote:
I have to applaud those who go out of their way to test on PostgreSQL. This is noble of you.
I may start doing it at some point even ... (I did some benchmarks with a guy from the list helping, sorry forgot his name).
I believe that was me. I'm sorry I haven't had more time to help out, but the personal issues I thought would be resolved by now are still a work in progress.
But think of it: how scalable and sustainable is this? What about other databases? Will you do that for MS SQL (while running Mac/Linux?) Oracle?
The problem with this community is that it's oddly divided. Is Drupal going to be database agnostic or not? If the opinion of the community is that supporting multiple databases is worthwhile, then folks need to bite the bullet, accept that doing so is a _lot_ of work, and quit whining.
The fellow who starts these threads every month or so needs to quit his damn whining and help out. His bitching is a constant distraction. And his excuse that he doesn't care about PostgreSQL is bull. If Karoly doesn't care about a particular Drupal module, should everyone else quit caring as well? If he doesn't want to support a less popular browser, like Firefox, should Drupal quit caring?
Being database agnostic is not an easy goal. The weak of resolve need not apply as they'll fail anyway. But it seems to me that most of the Drupal developers are not going to be easily dissuaded.
And why should they be? If Karoly convinced them to give up Postgres support, next he'd convince them to give up IE support, then he'd scare them away from some other challenge or another. Great projects don't get great by whining that "it's too hard" and backing down.
As many have pointed out, it's not really about PostgreSQL ... it's about supporting multiple databases. If Drupal drops PostgreSQL support, the overall goal of supporting multiple databases will suffer. The approaches that folks are taking to abstract the database are the correct approaches, but they're not as easy as just giving up, and they'll take time.
-- Bill Moran http://www.potentialtech.com
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
-- Bill Moran http://www.potentialtech.com
Bill Moran wrote: The only thing I know about Karoly is that he comes on this list about
every 30 days and starts whining about PostgreSQL. Looking at the page you directed me to, he has a lot of commits. That's great, does it make him immune to criticism?
I apologize to the community for stepping out of line.
Bill, The only thing I know about you, is that when Karoly posts on this list about postgresql holding up patches, you come on to whine about him posting on this list about postgresql holding up patches. However, I know that within the past six weeks, he's actually tested at least one patch on postgresql, and therefore does not live in a glass house.
his excuse that he doesn't care about PostgreSQL is bull. If Karoly doesn't care about a particular Drupal module, should everyone else quit caring as well? If he doesn't want to support a less popular browser, like Firefox, should Drupal quit caring?
When everyone else stopped caring and it hinders development, then what...? I am just stating the obvious. And unlike what Angie says, we have not stopped caring about aggregator and poll. I for one have written a poll simpletest and enhanced simpletest itself as I went.
Interesting news about MySQL http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ - John ********************************** John Callahan GIS Coordinator, Application Developer IT - User Services, University of Delaware 002A Smith Hall, Newark, DE 19716 302-831-1978 john.callahan@udel.edu **********************************
A clearer IMO article on the topic: http://www.nytimes.com/aponline/technology/AP-Sun-MySQL.html?_r=1&oref=slogi...
Guys/gals ... Please. No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal. Being database agnostic is a good thing. We all agree on that. The point Karoly is trying to make is that PostgreSQL keeps lagging behind because of lack of testing, and that holds back otherwise good patches. The noble people who are going out of their way to test PostgreSQL even though they don't use it are doing a good thing. But is it enough? Have the list of PostgreSQL issues diminished because of that? Remember way back when, 3 years ago, we had MS SQL support in core. Look at it here: http://cvs.drupal.org/viewvc.py/drupal/drupal/database/database.mssql?hideat... What happened? It went the way of the dodo. Unless something is done, PostgreSQL risks the same fate. And people who are already busy switching to PostgreSQL is not a sufficiently scalable answer. If there are any PostgreSQL users (or Oracle, or DB2 or MS SQL), then they either have to provide the manpower for the tests or pay testers to ensure their stuff works for future releases. Related point: We are talking here about just support for another database, not supporting big sites with database optimization, ...etc.
No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only.
On Jan 16, 2008 11:23 AM, <matt@mattfarina.com> wrote:
No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only.
We had 3 PostgreSQL maintainers in the last 3 years. All of them left. This leaves PostgreSQL in Limbo, not really a first class citizen, but neither officially abandoned, and hold back patches. So the problem is the current status quo. I am sure Karoly will be happy if a real maintainer shows up and stays. So the problem of delaying MySQL patches is gone. He wants database agnosticism too, but not the current status. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
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
I'm sorry to chime in on this topic which absolutely abracadabra for me. I have absolutely no sense about databases at all, but a consenses could be to: - make drupal 6 pgSQL and MySQL compatible and release the bastard; - at the same day we make a poll on drupal.org asking people what database type they use, and open up comments for those that choose pgSQL to tell us, why they do; That way we know: - how much people are actually using pgSQL; - and why they do it; Just some thought of someone who doesn't know anything about the differences between MySQL and pgSQL. I personally never used the latter... Stefan Op 16 jan 2008, om 18:05 heeft Konstantin Käfer het volgende geschreven:
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
On Jan 16, 2008 12:18 PM, Stefan Nagtegaal <development@robuustdesign.nl> wrote:
I'm sorry to chime in on this topic which absolutely abracadabra for me. I have absolutely no sense about databases at all, but a consenses could be to: - make drupal 6 pgSQL and MySQL compatible and release the bastard; - at the same day we make a poll on drupal.org asking people what database type they use, and open up comments for those that choose pgSQL to tell us, why they do;
That way we know: - how much people are actually using pgSQL; - and why they do it;
Michelle already pointed to an existing poll that shows how many pgSQL users there are. Here it is http://groups.drupal.org/node/6164
Just some thought of someone who doesn't know anything about the differences between MySQL and pgSQL. I personally never used the latter...
Stefan
Op 16 jan 2008, om 18:05 heeft Konstantin Käfer het volgende geschreven:
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
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And I have pointed out how meaningless of this poll once before. Here it is http://groups.drupal.org/node/6164#comment-18064 Khalid Baheyeldin wrote:
On Jan 16, 2008 12:18 PM, Stefan Nagtegaal <development@robuustdesign.nl <mailto:development@robuustdesign.nl>> wrote:
I'm sorry to chime in on this topic which absolutely abracadabra for me. I have absolutely no sense about databases at all, but a consenses could be to: - make drupal 6 pgSQL and MySQL compatible and release the bastard; - at the same day we make a poll on drupal.org <http://drupal.org> asking people what database type they use, and open up comments for those that choose pgSQL to tell us, why they do;
That way we know: - how much people are actually using pgSQL; - and why they do it;
Michelle already pointed to an existing poll that shows how many pgSQL users there are.
Here it is http://groups.drupal.org/node/6164
Just some thought of someone who doesn't know anything about the differences between MySQL and pgSQL. I personally never used the latter...
Stefan
Op 16 jan 2008, om 18:05 heeft Konstantin Käfer het volgende geschreven:
> 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 >> >
-- Khalid M. Baheyeldin 2bits.com <http://2bits.com>, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
- -- Edison Wong hswong3i@gmail.com http://edin.no-ip.com/html/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlFR9BPIQaq+ZRd8RAoX3AKCG4id6VC182yfAfQiiCfk27PP0swCfUwAj YXt66mCWliBN8xvFDD4+sZc= =UgCd -----END PGP SIGNATURE-----
Here is the blunt fact that too many people in this discussion keep ignoring: The claim is that we lose Postgres maintainers over and over. The claim is we don't have enough Postgres testing. And so forth and so on. The precise reason we don't have those things is because we really don't support Postgres. I myself do not run Postgres precisely because we don't support it. If we supported it, I would run it all the time and would test it and submit patches for it. But why should I waste extra time trying to do that if there is no push to make others write Postgres compatible code? It's like spitting into the wind, going against the tide, sailing upwind -- however you want to put it. It's a Catch 22, or a chicken and egg problem. If we don't "require" Postgres support by developers, most of them won't support it. As a result, every person who makes a choice about which database to use will be highly likely to choose MySQL because it is better supported. Then we have what we have now -- a self-reinforcing feedback loop that continues to encourage MySQL-only support. It's a self-fulfilling prophecy. We can choose to change this, or not. The only other way it changes is in the broader community: Sun ruins MySQL and everybody in the world outside of Drupal starts using Postgres instead. Then Drupal developers will start writing Postgres code because of outside influence. Either we support multiple databases, or we don't. And we get to choose. And hopefully I will remember long enough that I said this, and won't dip into this debate again. ;-)
No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only.
Supporting more than MySQL is important, especially for larger/integration projects. If Drupal did not have PostGreSQL support "1 year 42 weeks" ago, me and possibly some others would probably not be here today. Please don't mistake cause and effect. I still believe that there *are* enough postgres-guys already. However, there is no list for postgres-related issues that can be accessed easily.
On Jan 15, 2008, at 12:07 PM, Daniel F. Kudwien wrote:
Why don't we add another vocabulary for global issue categories like 'PostGreSQL', 'Performance', 'JavaScript', etc. ? ... Realization of this proposal would include that the category of an issue could be altered in an issue follow-up, and not just at the time of issue creation.
-Derek (dww)
Thanks for this hint, Derek. I didn't follow-up because I don't think a free-tagging vocab will help us here. IMHO, we need something we can put in the visible navigation for d.o users. Yes, free tags are not limited to a few terms. However, because of that, it's harder to build a fixed list of issue topics based on them.
On Jan 15, 2008, at 12:07 PM, Daniel F. Kudwien wrote:
Why don't we add another vocabulary for global issue categories like 'PostGreSQL', 'Performance', 'JavaScript', etc. ? ... Realization of this proposal would include that the category of an issue could be altered in an issue follow-up, and not just at the time of issue creation.
-Derek (dww)
Thanks for this hint, Derek. I didn't follow-up because I don't think a free-tagging vocab will help us here. IMHO, we need something we can put in the visible navigation for d.o users. Yes, free tags are not limited to a few terms. However, because of that, it's harder to build a fixed list of issue topics based on them.
Though the title of the issue Derek linked to above mentions free tagging, this could also be done with fixed vocabularies. For an example of how this might look, see the first screenshot posted at http://drupal.org/node/187480#comment-632130. Both of these vocabularies are free tagging, but fixed vocabularies would look similar. The comment_alter_taxonomy module that I will finish once the requisite patches to project_issue have been committed will handle diffing taxonomy terms for both free tagging and fixed vocabularies. Obviously in the case of fixed vocabularies a user would not be able to add a new term to the vocabulary itself in a comment. Adam
On Jan 16, 2008 4:58 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only.
Supporting more than MySQL is important, especially for larger/integration projects. If Drupal did not have PostGreSQL support "1 year 42 weeks" ago, me and possibly some others would probably not be here today.
Please don't mistake cause and effect. I still believe that there *are* enough postgres-guys already. However, there is no list for postgres-related issues that can be accessed easily.
Are you aware of this list? http://groups.drupal.org/node/6980
Patch reviewers could also be diligent about setting the 'Components' flag to 'postgresql database' on issues that need pgSQL review. Then people can run advanced search from: http://drupal.org/project/issues/search/drupal There are currently only 2 such current [1] issues tagged for rc2 or 6.x-dev . - Ken Rickard agentrickard [1] Where current issues states are other than closed, duplicate, won't fix, or by design. On Jan 16, 2008 5:20 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 16, 2008 4:58 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
No one is advocating that Drupal be MySQL only. No one is advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only.
Supporting more than MySQL is important, especially for larger/integration projects. If Drupal did not have PostGreSQL support "1 year 42 weeks" ago, me and possibly some others would probably not be here today.
Please don't mistake cause and effect. I still believe that there *are* enough postgres-guys already. However, there is no list for postgres-related issues that can be accessed easily.
Are you aware of this list? http://groups.drupal.org/node/6980
-- -- -------------------------------------------------------------- DON'T MISS EARTH'S LARGEST GATHERING OF DRUPAL PROFESSIONALS! Drupalcon Boston 2008 · March 3-6, 2008 Learn more at http://boston2008.drupalcon.org Affordable sponsorship packages available --------------------------------------------------------------
I am *no fan of Microsoft* but I have just been reading *Showstopper*, which is an extraordinarily insightful look into the internals of the company in the 1990s. I think that the following is extremely relevant to Drupal and that Dave Cutler had it exactly right. (He must be despairing of what Microsoft later did to his "pure" design). Here is a quote: Since the start of the project, Cutler had emphasized the importance of creating two versions of NT in tandem. This kept code writers "honest" by forcing them to write their code in portable languages, rather than lapsing in to chip-specific assembly code. Proudly dubbing himself Mr. Mips, Cutler was more enthusiastic about the version of NT designed for the Mips chip. This was… because… Cutler feared that the Mips version would receive short shrift unless someone of his stature defended it. It was all too easy to tailor NT to Intel's X86 chips, giving the program greater performance but at the cost of portability. This was the path advocated by Muglia, who was convince that Intel chips would power virtually every PC for years to come. "Screw Mips," he said. The team should "focus on the Intel version and let Mips drag behind." To Cutler, Muglia's position was stupid. If the team let the Mips version of NT lag behind, within months there would be no Mips version. Without a constant effort to keep the two versions in line, they would drift hopelessly apart. Day to day Cultler's top propriety was to keep the two versions on an equal footing. As one code writer put it. "That guarantees you portability and verifies your design." ** The parallel with the MySQL/Postgres debate is clear, and the arguments are identical. *Showstopper!: the breakneck race to create Windows NT and the next generation at Microsoft* by G. Pascal Zachary (Free Press: NY, 1994), p.161. On Jan 16, 2008 10:31 PM, Ken Rickard <agentrickard@gmail.com> wrote:
Patch reviewers could also be diligent about setting the 'Components' flag to 'postgresql database' on issues that need pgSQL review. Then people can run advanced search from: http://drupal.org/project/issues/search/drupal There are currently only 2 such current [1] issues tagged for rc2 or 6.x-dev. - Ken Rickard agentrickard [1] Where current issues states are other than closed, duplicate, won't fix, or by design. On Jan 16, 2008 5:20 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 16, 2008 4:58 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
No one is advocating that Drupal be MySQL only. No one is > advocating that we rip out PostgreSQL support from Drupal.
I've read where Karoly wrote that we should be mysql only. Not arguing either way. Just pointing out there are those who think we should be mysql only. Supporting more than MySQL is important, especially for larger/integration projects. If Drupal did not have PostGreSQL support "1 year 42 weeks" ago, me and possibly some others would probably not be here today. Please don't mistake cause and effect. I still believe that there *are* enough postgres-guys already. However, there is no list for postgres-related issues that can be accessed easily.
Are you aware of this list? http://groups.drupal.org/node/6980
-- -- -------------------------------------------------------------- DON'T MISS EARTH'S LARGEST GATHERING OF DRUPAL PROFESSIONALS! Drupalcon Boston 2008 · March 3-6, 2008 Learn more at http://boston2008.drupalcon.org Affordable sponsorship packages available --------------------------------------------------------------
On Sat, 19 Jan 2008 16:14:27 -0500 "Andrew ft" <andrewft@gmail.com> wrote:
The parallel with the MySQL/Postgres debate is clear, and the arguments are identical.
If it wasn't for the fact that MS and Intel are 2 monopolies and Joomla, Drupal, Postgresql, MySQL... are Free software. I'm not pointing this out for "idealistic" reasons... just because different starting point lead to different conclusions. So Cutler may have been technically right and Muglia market right... but I wouldn't apply the same rules to Drupal. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On sam, 2008-01-19 at 16:14 -0500, Andrew ft wrote:
The parallel with the MySQL/Postgres debate is clear, and the arguments are identical.
And so what? Are we supposed to start a flame war now? Sorry, I don't have enough energy for such a discussion. Working in team during a long time is important in a free software project. I am new here, so I wron't say. Give me a few weeks to lear the code, then we can discuss about your questions. But just a few words: PostgreSQL is an SQL99 reference database. When you develop SQL code for PostgreSQL, you can silently run the code under any database. On the converse, when designing SQL for a non-standard database, you are more likely to loose time. Besides, to be more positive, I wrote part of pgAdmin 1&2 PostgreSQL client for PostgreSQL. Now pgAdmin 3 is available and is developped by a team. It did not write a single line in version 3. But try to use it. It may change your mind about PostgreSQL. PostgreSQL is a real community of very pleasant people. We are not a company, but a real team. Posting against PostgreSQL will certainly attract hundreds of PostgreSQL developers. Is that you silent dream? Kind regards, Jean-Michel Pouré
PostgreSQL is an SQL99 reference database. When you develop SQL code for PostgreSQL, you can silently run the code under any database.
On the converse, when designing SQL for a non-standard database, you are more likely to loose time.
That is all well and good from "it runs" (i.e. unit testing, functionality is OK), but when you try to optimize for large datasets or complex queries, you often have to do things that are database engine specific. This is a classic clash been theory and reality. PostgreSQL is a real community of very pleasant people. We are not a
company, but a real team. Posting against PostgreSQL will certainly attract hundreds of PostgreSQL developers. Is that you silent dream?
That is also good, but it is not the point. We are not debating whether Pg or MySQL are better database, or who has a better community. The bottleneck is how many developers know PostgreSQL AND care about Drupal using PostgreSQL, and willing to put in the effort to keep in tandem with MySQL so PostgreSQL does not lag behind. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
Dear friends,
That is all well and good from "it runs" ( i.e. unit testing, functionality is OK), but when you try to optimize for large datasets or complex queries, you often have to do things that are database engine specific.
This is a classic clash been theory and reality.
Sorry, not my opinion. MySQL employs non-standard SQL queries. If the code was written primarily for PostgreSQL using tables, standard sql queries and views, it would run smoothly on MySQL and most databases like Oracle and DB2. This is because PostgreSQL is the standard SQL99 implementation. Very few things differ in PostgreSQL. The converse is not true.
The bottleneck is how many developers know PostgreSQL AND care about Drupal using PostgreSQL, and willing to put in the effort to keep in tandem with MySQL so PostgreSQL does not lag behind.
I recommand using pgAdmin III graphical client, which is the standard graphical interface for PostgreSQL. Also, log and analyse all SQL queries and plans. Like in my HOWTO : PostgreSQL query optimisation => http://area51.phpbb.com/phpBB/viewtopic.php?f=3&t=29292 It is pretty hard against MySQL. Sorry, this is the opinion of most people designing databases. I may change my opinion when a better transactional support is added with better SQL99 suppport. Besides, I find Drupal sometimes slow on my testing installation. I will try to debug SQL queries written for MySQL and will report them back. Kind regards, Jean-Michel
On Jan 21, 2008 7:42 AM, Jean-Michel Pouré <jm@poure.com> wrote:
Dear friends,
That is all well and good from "it runs" ( i.e. unit testing, functionality is OK), but when you try to optimize for large datasets or complex queries, you often have to do things that are database engine specific.
This is a classic clash been theory and reality.
Sorry, not my opinion. MySQL employs non-standard SQL queries.
If the code was written primarily for PostgreSQL using tables, standard sql queries and views, it would run smoothly on MySQL and most databases like Oracle and DB2.
This is because PostgreSQL is the standard SQL99 implementation. Very few things differ in PostgreSQL.
The converse is not true.
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?
The bottleneck is how many developers know PostgreSQL AND care about Drupal using PostgreSQL, and willing to put in the effort to keep in tandem with MySQL so PostgreSQL does not lag behind.
I recommand using pgAdmin III graphical client, which is the standard graphical interface for PostgreSQL.
Also, log and analyse all SQL queries and plans.
Like in my HOWTO : PostgreSQL query optimisation => http://area51.phpbb.com/phpBB/viewtopic.php?f=3&t=29292
How is this going to help with the main issue (lack of human resources on the PostgreSQL side)? People who develop and deploy Drupal use mainly MySQL. Should we give them more work to solve the problem of lack or resource (or the pgSQL folk not contributing)?
It is pretty hard against MySQL. Sorry, this is the opinion of most people designing databases. I may change my opinion when a better transactional support is added with better SQL99 suppport.
pgSQL is a better database than MySQL (at least MyISAM). No one is saying otherwise. The issue is how the community is made up, not a technical one.
Besides, I find Drupal sometimes slow on my testing installation. I will try to debug SQL queries written for MySQL and will report them back.
Kind regards, Jean-Michel
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
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
21 jan 2008 kl. 20.49 skrev Jean-Michel Pouré:
I am only arguying that if you were developing Drupal on PostgreSQL, it would solve the portability issue.
This is a good point. But there is also MySQL's "strict mode" (STRICT_TRANS_TABLES, STRICT_ALL_TABLES, ANSI etc.): http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html If all developers enabled that we would probably avoid a lot of portability issues. However I wasn't able to find any information about it in the developer's docs. I'm not so familiar with these things myself so I'm hoping someone else could add a few lines about it. Anyone? /Hannes - zoo33
On Jan 19, 2008 7:14 PM, Andrew ft <andrewft@gmail.com> wrote:
The parallel with the MySQL/Postgres debate is clear, and the arguments are identical.
I wonder if Cutler ignored issues in the queue that needed a review that were spoonfed to him with patches written by someone who didn't use Mips but who wanted to maintain compatability. If that were the case then we'd have a identical situation. </flamebait> For the people who said that these threads are useless and that Karoly is foolish to start them, note that the original issue finally got reviews and attention...after being posted here. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
It is the other way around: Cutler supported the *minority* platform because it would keep the code "honest" and not allow them to start relying on Intel-only hacks. On Jan 19, 2008 5:39 PM, Greg Knaddison - GVS < Greg@growingventuresolutions.com> wrote:
On Jan 19, 2008 7:14 PM, Andrew ft <andrewft@gmail.com> wrote:
The parallel with the MySQL/Postgres debate is clear, and the arguments are identical.
I wonder if Cutler ignored issues in the queue that needed a review that were spoonfed to him with patches written by someone who didn't use Mips but who wanted to maintain compatability. If that were the case then we'd have a identical situation.
</flamebait>
For the people who said that these threads are useless and that Karoly is foolish to start them, note that the original issue finally got reviews and attention...after being posted here.
Greg
-- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Jan 19, 2008 6:39 PM, Andrew Fountain <af@loveintruth.com> wrote:
It is the other way around: Cutler supported the *minority* platform because it would keep the code "honest" and not allow them to start relying on Intel-only hacks.
Yes, that is a worthy cause, but there are differences: - This is open source, not a commercial entity with lots of funding. People scratch their OWN itch. Someone else can scratch another itch. If, as a consultant, I deploy Drupal on MySQL exclusively, should I use PostgreSQL in-house just to side with the minority, or focus the limited resources I have on what matters to clients? - There was a third architecture that Windows NT supported: DEC Alpha, strangely enough from the company that Cutler came from where he designed VMS. All of the non-Intel architectures died after a very short life span, never mind the good intentions and idealism. Side point: Sun Microsystems invested heavily in PostgreSQL 2 or so years ago, and provided support for it. Now they turned around and bought MySQL for $1B. PostgreSQL is not a company that can be bought, but a community project/product (like Drupal). What will happen next? Time will tell.
Khalid Baheyeldin wrote:
On Jan 19, 2008 6:39 PM, Andrew Fountain <af@loveintruth.com> wrote:
Yes, that is a worthy cause, but there are differences:
- This is open source, not a commercial entity with lots of funding. People scratch their OWN itch. Someone else can scratch another itch. If, as a consultant, I deploy Drupal on MySQL exclusively, should I use PostgreSQL in-house just to side with the minority, or focus the limited resources I have on what matters to clients?
Hei 'The minority' is something I am hearing all the time. Do we have numbers that can give us any statistics about the amount of systems using drupal and postgresql? Because I suspect that they are not as few as some would like them to be. -- Rafael Martinez, <r.m.guerrero@usit.uio.no> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/
'The minority' is something I am hearing all the time. Do we have numbers that can give us any statistics about the amount of systems using drupal and postgresql? Because I suspect that they are not as few as some would like them to be.
This is what we have. You can see it is quite a minority. http://groups.drupal.org/node/6164 Even if the above data was not available, and PostgreSQL is a majority, it it is still a moot point. Every year, we have a new maintainer, then he disappears. I don't think we even have one at present. The fact that it is a challenge to get people to test and push PostgreSQL patches through the patch queue is the big hindrance. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
Khalid Baheyeldin wrote:
'The minority' is something I am hearing all the time. Do we have numbers that can give us any statistics about the amount of systems using drupal and postgresql? Because I suspect that they are not as few as some would like them to be.
This is what we have. You can see it is quite a minority.
http://groups.drupal.org/node/6164
Even if the above data was not available, and PostgreSQL is a majority, it it is still a moot point.
Every year, we have a new maintainer, then he disappears. I don't think we even have one at present.
The fact that it is a challenge to get people to test and push PostgreSQL patches through the patch queue is the big hindrance.
Well, if we could say that the data in this page "What DB drives your Drupal?" is representative, a 11% of the users is a minority, but we are talking about around 66.000 (11% of 600.000 downloads) websites if the data in http://buytaert.net/tag/statistics is also representative. You don't know neither what kind of users are these 60.000. Are they running large, corporate or intratet sites or small local websites at home? I have the feeling that we are not talking about small systems here. My point is that I think that stopping supporting postgresql is a bad, bad idea and it would get many supporters/users upset. You already have a database abstraction layer. The only problem here is the different SQL statements send to the database. More use of standard SQL insteed of MySQL specific statements will help to minimize the differents between the two databases regarding the code. We could even use other ways of interacting with the database, like stored procedures, but this is another discussion. I am also sure that many postgresql DBAs will help with this issue if it gets easier to do this. For example, I do not have time to learn the internals of Drupal's code (I am a DBA), but it will be a pleasure to help if I could get a list with all SQL statements send to the database and a test-case database with test data. It would take us very little time to find out and fix specific MySQL SQL statements that will have problems running on postgresql. My 5 cents ..... Let's make a great product like Drupal even better insteed of destroying his good reputation. regards -- Rafael Martinez, <r.m.guerrero@usit.uio.no> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/
On Jan 20, 2008 8:02 AM, Rafael Martinez <r.m.guerrero@usit.uio.no> wrote:
Khalid Baheyeldin wrote:
'The minority' is something I am hearing all the time. Do we have numbers that can give us any statistics about the amount of systems using drupal and postgresql? Because I suspect that they are not as few as some would like them to be.
This is what we have. You can see it is quite a minority.
http://groups.drupal.org/node/6164
Even if the above data was not available, and PostgreSQL is a majority, it it is still a moot point.
Every year, we have a new maintainer, then he disappears. I don't think we even have one at present.
The fact that it is a challenge to get people to test and push PostgreSQL patches through the patch queue is the big hindrance.
Well, if we could say that the data in this page "What DB drives your Drupal?" is representative, a 11% of the users is a minority, but we are talking about around 66.000 (11% of 600.000 downloads) websites if the data in http://buytaert.net/tag/statistics is also representative.
As Khalid said - number of users is not as important as willingness and speed to patch/review issues.
You don't know neither what kind of users are these 60.000. Are they running large, corporate or intratet sites or small local websites at home? I have the feeling that we are not talking about small systems here.
If they are all big businesses, all the more reason for them to have budget and time available to patch/review issues.
My point is that I think that stopping supporting postgresql is a bad, bad idea and it would get many supporters/users upset.
Nobody suggested that. People suggested committing patches for PostgreSQL if they are reasonably certain to work and holding back the rest of development.
You already have a database abstraction layer. The only problem here is the different SQL statements send to the database. More use of standard SQL insteed of MySQL specific statements will help to minimize the differents between the two databases regarding the code. We could even use other ways of interacting with the database, like stored procedures, but this is another discussion.
I am also sure that many postgresql DBAs will help with this issue if it gets easier to do this. For example, I do not have time to learn the internals of Drupal's code (I am a DBA), but it will be a pleasure to help if I could get a list with all SQL statements send to the database and a test-case database with test data. It would take us very little time to find out and fix specific MySQL SQL statements that will have problems running on postgresql.
Great! The problem isn't so much existing queries, but more queries that are being debated to add. You can see a list of issues like that here: http://groups.drupal.org/node/6980 I suggest you join that group as well if you haven't. In order to test them you'd need to maintain a Drupal-HEAD installation on a PostgreSQL backend.
My 5 cents ..... Let's make a great product like Drupal even better insteed of destroying his good reputation.
Well, we're all trying to "make Drupal better," but we have different ideas about how to do that. Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Khalid Baheyeldin wrote:
The point Karoly is trying to make is that PostgreSQL keeps lagging behind because of lack of testing, and that holds back otherwise good patches.
Hi, I was thinking I might have a look at these patches and see if I can help .. is there a convenient list somewhere? -- Sean Burlington
http://groups.drupal.org/node/6980 On Jan 16, 2008 4:47 PM, Sean Burlington <sean@burlington.me.uk> wrote:
Khalid Baheyeldin wrote:
The point Karoly is trying to make is that PostgreSQL keeps lagging behind because of lack of testing, and that holds back otherwise good patches.
Hi,
I was thinking I might have a look at these patches and see if I can help ..
is there a convenient list somewhere?
--
Sean Burlington
is there a convenient list somewhere?
As said in the thread starter mail: http://groups.drupal.org/node/6980 Also, I do not want single database support, no. I want SQLite and MySQL in Drupal 7. postgresql, thanks, not. SQLite (maybe with in memory database?) could mean that install is no longer a bastard but runs a minimal install of Drupal.
Who do you refer? You removed all quote, we have no idea who is noble!! Feijó ----- Original Message ----- From: Khalid Baheyeldin To: development@drupal.org Sent: Wednesday, January 16, 2008 1:16 AM Subject: Re: [development] So why we do support postgresql? I have to applaud those who go out of their way to test on PostgreSQL. This is noble of you. I may start doing it at some point even ... (I did some benchmarks with a guy from the list helping, sorry forgot his name). But think of it: how scalable and sustainable is this? What about other databases? Will you do that for MS SQL (while running Mac/Linux?) Oracle?
participants (26)
-
Adam Light -
Alessandro Feijó -
Andrew Fountain -
Andrew ft -
Bevan Rudge -
Bill Moran -
catch -
Chris Johnson -
Daniel F. Kudwien -
Edison Wong -
Greg Knaddison - GVS -
Hannes Lilljequist -
Ivan Sergio Borgonovo -
Jean-Michel Pouré -
John Callahan -
Karoly Negyesi -
Ken Rickard -
Khalid Baheyeldin -
Konstantin Käfer -
matt＠mattfarina.com -
Michelle Cox -
Oleg Terenchuk -
Rafael Martinez -
Sean Burlington -
Stefan Nagtegaal -
Stephane Corlosquet