Thread: PostgreSQL vs. SQL Server, Oracle
Press coverage, an interview with Neil Matthew and Richard Stones. http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: kaare@jasonic.dk
On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote: > Press coverage, an interview with Neil Matthew and Richard Stones. > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html With friends like these... "In an emergency, having companies the size of Microsoft or Oracle to call on may significantly mitigate that risk." My experiences calling these outfits in an emergency have been a lot less than uniformly good, even with their top-cost levels of support. Blaming one of these outfits may save some manager's job, but that's not the same as actually having the emergency resolved promptly, or better still, not having it happen at all. "First, the ability to write functions and stored procedures is somewhat more limited than you would get with Oracle's PL/SQL or Sybase's T-SQL." I don't know which languages they were looking at, but it's hard to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby, PL/sh, etc. from a flexibility perspective. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote:
> "First, the ability to write functions and stored procedures is
> somewhat more limited than you would get with Oracle's PL/SQL or
> Sybase's T-SQL."
>
> I don't know which languages they were looking at, but it's hard to
> imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
> PL/sh, etc. from a flexibility perspective.
>
Or C, for that matter. Doesn't get much less "limited" than allowing C
functions with a very powerful SPI. It's hard to argue with them when
they don't provide a single example, however.
Regards,
Jeff Davis
Jeff Davis wrote:
> On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote:
>> "First, the ability to write functions and stored procedures is
>> somewhat more limited than you would get with Oracle's PL/SQL or
>> Sybase's T-SQL."
>>
>> I don't know which languages they were looking at, but it's hard to
>> imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
>> PL/sh, etc. from a flexibility perspective.
>>
>
> Or C, for that matter. Doesn't get much less "limited" than allowing C
> functions with a very powerful SPI. It's hard to argue with them when
> they don't provide a single example, however.
O.k. guys, the article wasn't perfect but it was a heck of a lot more
fair an accurate then what we usually see from the press.
I have already written the editor with a note about the misconception of
our procedural languages.
Joshua D. Drake
>
> Regards,
> Jeff Davis
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
On Wed, Oct 11, 2006 at 10:43:39AM -0700, Joshua D. Drake wrote: > Jeff Davis wrote: > > On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote: > >> "First, the ability to write functions and stored procedures is > >> somewhat more limited than you would get with Oracle's PL/SQL or > >> Sybase's T-SQL." > >> > >> I don't know which languages they were looking at, but it's hard > >> to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, > >> PL/Ruby, PL/sh, etc. from a flexibility perspective. > > > > Or C, for that matter. Doesn't get much less "limited" than > > allowing C functions with a very powerful SPI. It's hard to argue > > with them when they don't provide a single example, however. > > O.k. guys, the article wasn't perfect but it was a heck of a lot > more fair an accurate then what we usually see from the press. I'd think you of all people would be a little peeved at having your support dismissed this way by their failure to mention that your kind of support was available. > I have already written the editor with a note about the > misconception of our procedural languages. That's a start :) You'll notice what I started this off with, which is "With friends like these..." These guys wrote a book on PostgreSQL. They should know better, but for some reason have decided to spread a bunch of FUD. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On 10/11/06, Joshua D. Drake <jd@commandprompt.com> wrote: > O.k. guys, the article wasn't perfect but it was a heck of a lot more > fair an accurate then what we usually see from the press. True. > I have already written the editor with a note about the misconception of > our procedural languages. True, however, it goes to show the authors level of knowledge when researching and churning out the book. You'd think there at least would've been a mention of extending the procedural language. Of course, Oracle supports C and Java stored procedures and Microsoft supports procedures with the Common Language Runtime... so I don't think it's a fair comparison to say, "PostgreSQL can do it and others can't" just because they didn't mention PL extensibility. Just my 2 cents. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 10/11/06, David Fetter <david@fetter.org> wrote: > I'd think you of all people would be a little peeved at having your > support dismissed this way by their failure to mention that your kind > of support was available. Neither was ours, but that's not the point behind open source and PostgreSQL... PostgreSQL is free and available for community-based support... there's nothing wrong with that and I don't consider it a dismissal at all. > That's a start :) You'll notice what I started this off with, which > is "With friends like these..." These guys wrote a book on > PostgreSQL. They should know better, but for some reason have decided > to spread a bunch of FUD. Honestly, these guys are professional authors who churn out book after book. They do a little research and write the book; it's in no way representative of the in-depth knowledge available in the community... just a good place to start. I don't think they were spreading FUD, just aiming statements for small/medium businesses who are paying big bucks for Oracle, SQL Server, et al. They aren't PostgreSQL professionals... just authors trying to promote PostgreSQL a little bit. Chill out man :) -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
>
> I'd think you of all people would be a little peeved at having your
> support dismissed this way by their failure to mention that your kind
> of support was available.
Honestly, I got over that a *long* time ago. The reality is, people who
want to use postgresql, do the research themselves and then call us (if
they need us). If you recall I don't have any car salesmen, like other
companies. People that do business with us, because of our resume not
because some guy in a tie with a split tongue told them that we are the
best postgresql company out there.
Could we get more business if the press was more accurate? Sure... but
then again if the press was more accurate, they wouldn't be able to sell
any advertising.
>
>> I have already written the editor with a note about the
>> misconception of our procedural languages.
>
> That's a start :) You'll notice what I started this off with, which
> is "With friends like these..." These guys wrote a book on
> PostgreSQL. They should know better, but for some reason have decided
> to spread a bunch of FUD.
I didn't get any FUD from the article is my point. I just got ignorance
but perceptions vary. I can see your frustration from the fact that they
wrote a book on it but writing a book is easy. Writing a good book is hard.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
On Wed, 2006-10-11 at 10:43 -0700, Joshua D. Drake wrote:
> > Or C, for that matter. Doesn't get much less "limited" than allowing C
> > functions with a very powerful SPI. It's hard to argue with them when
> > they don't provide a single example, however.
>
> O.k. guys, the article wasn't perfect but it was a heck of a lot more
> fair an accurate then what we usually see from the press.
>
I would agree with you except that it was the first problem he
mentioned. Table partitioning and vendor tools were second and third,
respectively. That doesn't seem odd to you?
I can't even recall a single complaint about PostgreSQL's functions in
recent history.
However, you're right, I shouldn't complain since the press is probably
good overall.
> I have already written the editor with a note about the misconception of
> our procedural languages.
>
Thanks, a nicely worded note to the editor is always good.
Regards,
Jeff Davis
David Fetter wrote: >> http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html > > With friends like these... > > "In an emergency, having companies the size of Microsoft or Oracle to > call on may significantly mitigate that risk." Thanks to Fujitsu you have a bigger company supporting PostgreSQL than Oracle. I believe if you want a > $40 Billion revenue company supporting your database, your only choices are SQL Server, DB2, and PostgreSQL (Fujitsu's 4.8 billion yen revenue is about 40 billion/yr makes it the world's third largest IT services provider). With such alternatives, you wouldn't want to trust your business to a database only supported by a small company like Oracle ($15B/yr), would you?
On Wednesday 11 October 2006 12:41, David Fetter wrote: > On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote: > > Press coverage, an interview with Neil Matthew and Richard Stones. > > > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.h > >tml > > With friends like these... > > "In an emergency, having companies the size of Microsoft or Oracle to > call on may significantly mitigate that risk." > > My experiences calling these outfits in an emergency have been a lot > less than uniformly good, even with their top-cost levels of support. > Blaming one of these outfits may save some manager's job, but that's > not the same as actually having the emergency resolved promptly, or > better still, not having it happen at all. > > "First, the ability to write functions and stored procedures is > somewhat more limited than you would get with Oracle's PL/SQL or > Sybase's T-SQL." > > I don't know which languages they were looking at, but it's hard to > imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby, > PL/sh, etc. from a flexibility perspective. > I'm not sure why people in this community are so quick to label anyone who is less than glowing about postgresql as "the enemy", but it's really annoying. Maybe these guys were thinking about things like the ability to return multiple resultsets and/or the ability to do multiple transactions within a stored procedure; both of which are functionality that Oracle and SQL Server devotee's have been enjoying for years... (for the curious, see relevant threads in the -hackers archives about implementation proposals to add these features that as of yet have not gotten off the ground) -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Wed, 2006-10-11 at 20:18 -0400, Robert Treat wrote:
> I'm not sure why people in this community are so quick to label anyone who is
> less than glowing about postgresql as "the enemy", but it's really annoying.
I didn't take the "with friends like these..." comment literally, but I
see how many people would interpret that to mean he's an enemy, which he
isn't.
> Maybe these guys were thinking about things like the ability to return
> multiple resultsets and/or the ability to do multiple transactions within a
> stored procedure; both of which are functionality that Oracle and SQL Server
> devotee's have been enjoying for years... (for the curious, see relevant
> threads in the -hackers archives about implementation proposals to add these
> features that as of yet have not gotten off the ground)
I don't think it's fair to say "not gotten off the ground". Most of the
use cases that people were concerned about with multiple transactions in
a function/procedure were solved with the addition of savepoints. I
understand that people still want procedures that are executed outside
any other transactions, but I think significant progress was made
responding to many of the needs. I understand your point though.
Regards,
Jeff Davis
On Wed, Oct 11, 2006 at 08:18:18PM -0400, Robert Treat wrote: > On Wednesday 11 October 2006 12:41, David Fetter wrote: > > On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote: > > > Press coverage, an interview with Neil Matthew and Richard Stones. > > > > > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.h > > >tml > > > > With friends like these... > > > > "In an emergency, having companies the size of Microsoft or Oracle > > to call on may significantly mitigate that risk." > > > > My experiences calling these outfits in an emergency have been a > > lot less than uniformly good, even with their top-cost levels of > > support. Blaming one of these outfits may save some manager's > > job, but that's not the same as actually having the emergency > > resolved promptly, or better still, not having it happen at all. > > > > "First, the ability to write functions and stored procedures is > > somewhat more limited than you would get with Oracle's PL/SQL or > > Sybase's T-SQL." > > > > I don't know which languages they were looking at, but it's hard > > to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, > > PL/Ruby, PL/sh, etc. from a flexibility perspective. > > I'm not sure why people in this community are so quick to label > anyone who is less than glowing about postgresql as "the enemy", but > it's really annoying. I didn't do that. I called them friends, if not very clueful ones. > Maybe these guys were thinking about things like the ability to > return multiple resultsets and/or the ability to do multiple > transactions within a stored procedure; Then they should have mentioned it. PostgreSQL has real issues, and if they'd mentioned any one of these, it would have been reasonable. Instead, these guys chose to spread the FUD around and call PostgreSQL a toy. > both of which are functionality that Oracle and SQL Server devotee's > have been enjoying for years... (for the curious, see relevant > threads in the -hackers archives about implementation proposals to > add these features that as of yet have not gotten off the ground) Part of why they haven't gotten off the ground is that it's been possible for at least 3 years to return SETOF REFCURSOR from functions, and there's your multiple result sets :) As far as multiple transactions, we have had SAVEPOINTs for quite awhile and it's possible to do 'autonomous transactions' through untrusted PLs. I agree that none of what I just mentioned is ideal, but it means that the capability is there, and so a lot of people who work on internals are faced with a choice: Make existing functionality prettier, or do things that can't currently be done. If we had a bunch more people on salary doing this, as I hope we will soon, that choice won't be as stark. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Wednesday 11 October 2006 21:36, David Fetter wrote: > On Wed, Oct 11, 2006 at 08:18:18PM -0400, Robert Treat wrote: > > On Wednesday 11 October 2006 12:41, David Fetter wrote: > > > On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote: > > > > Press coverage, an interview with Neil Matthew and Richard Stones. > > > > > > > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466, > > > >00.h tml > > > > > > With friends like these... > > > > > > "In an emergency, having companies the size of Microsoft or Oracle > > > to call on may significantly mitigate that risk." > > > > > > My experiences calling these outfits in an emergency have been a > > > lot less than uniformly good, even with their top-cost levels of > > > support. Blaming one of these outfits may save some manager's > > > job, but that's not the same as actually having the emergency > > > resolved promptly, or better still, not having it happen at all. > > > > > > "First, the ability to write functions and stored procedures is > > > somewhat more limited than you would get with Oracle's PL/SQL or > > > Sybase's T-SQL." > > > > > > I don't know which languages they were looking at, but it's hard > > > to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, > > > PL/Ruby, PL/sh, etc. from a flexibility perspective. > > > > I'm not sure why people in this community are so quick to label > > anyone who is less than glowing about postgresql as "the enemy", but > > it's really annoying. > > I didn't do that. I called them friends, if not very clueful ones. > Is that how you treat all your "friends" ? > > Maybe these guys were thinking about things like the ability to > > return multiple resultsets and/or the ability to do multiple > > transactions within a stored procedure; > > Then they should have mentioned it. PostgreSQL has real issues, and > if they'd mentioned any one of these, it would have been reasonable. > Instead, these guys chose to spread the FUD around and call PostgreSQL > a toy. Now who is spreading FUD? Show me where they said PostgreSQL was a toy? > > > both of which are functionality that Oracle and SQL Server devotee's > > have been enjoying for years... (for the curious, see relevant > > threads in the -hackers archives about implementation proposals to > > add these features that as of yet have not gotten off the ground) > > Part of why they haven't gotten off the ground is that it's been > possible for at least 3 years to return SETOF REFCURSOR from > functions, and there's your multiple result sets :) > As far as > multiple transactions, we have had SAVEPOINTs for quite awhile and > it's possible to do 'autonomous transactions' through untrusted PLs. > You're starting to sound more like those database guys who thought FK's were unneccessary and transactions were overrated every day... I just can't decide if it's due to zealotry or a lack of experience with other systems. > I agree that none of what I just mentioned is ideal, but it means that > the capability is there, and so a lot of people who work on internals > are faced with a choice: Make existing functionality prettier, or do > things that can't currently be done. If we had a bunch more people on > salary doing this, as I hope we will soon, that choice won't be as > stark. > I'm not questioning the choices the hackers have made, I'm questioning the tactic of trashing people who are promoting postgresql just because they don't bath in the same flavor of kool-aid as you. You yourself just said "I agree that none of what I just mentioned is ideal", (which as someone who has actually worked on systems using all of your above methods I'd say is being generous) but somehow when they say that PostgreSQL is "somewhat more limited" your reaction is a backhanded email to the advocacy group. I'd prefer people recognize the high points of the article and then educate themselves on why two postgresql supporters might question postgresql's use in certain areas so that we know better how to tackle those problems both in code and from an advocacy point of view. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
David, > Then they should have mentioned it. PostgreSQL has real issues, and > if they'd mentioned any one of these, it would have been reasonable. > Instead, these guys chose to spread the FUD around and call PostgreSQL > a toy. That's not how I read the article. They recommended PostgreSQL for "edge" applications, which is the conventional opinion on Open Source databases. From my perspective, it's a positive article for us: "Try PostgreSQL, you might like it." -- Josh Berkus PostgreSQL @ Sun San Francisco
On Wed, Oct 11, 2006 at 10:55:33PM -0700, Josh Berkus wrote: > David, > > > Then they should have mentioned it. PostgreSQL has real issues, and > > if they'd mentioned any one of these, it would have been reasonable. > > Instead, these guys chose to spread the FUD around and call PostgreSQL > > a toy. > > That's not how I read the article. They recommended PostgreSQL for "edge" > applications, which is the conventional opinion on Open Source databases. > From my perspective, it's a positive article for us: "Try PostgreSQL, you > might like it." Not only that, but I think the very last answer really hit the nail on the head when it comes to MySQL and PostgreSQL: there's no need to take MySQL's trade-offs for even your light-weight applications. The reality is, very few companies are willing to bet their a..erm, donkey ;) on PostgreSQL... yet. Remember that most of the people at a level that can make that decision have probably barely even heard about PostgreSQL, so it's no surprise they're not ready to bet the farm on it. Given time and sucessful deployments in less-critical areas, this will change. Especially if the big 3 keep their pricing where it is... -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Thu, Oct 12, 2006 at 02:50:25PM -0500, Jim C. Nasby wrote: > On Wed, Oct 11, 2006 at 10:55:33PM -0700, Josh Berkus wrote: > > David, > > > > > Then they should have mentioned it. PostgreSQL has real issues, > > > and if they'd mentioned any one of these, it would have been > > > reasonable. Instead, these guys chose to spread the FUD around > > > and call PostgreSQL a toy. > > > > That's not how I read the article. They recommended PostgreSQL > > for "edge" applications, which is the conventional opinion on Open > > Source databases. From my perspective, it's a positive article > > for us: "Try PostgreSQL, you might like it." > > Not only that, but I think the very last answer really hit the nail > on the head when it comes to MySQL and PostgreSQL: there's no need > to take MySQL's trade-offs for even your light-weight applications. True. > The reality is, very few companies are willing to bet their a..erm, > donkey ;) on PostgreSQL... yet. I think this was true two years ago, but just about anybody here can name a whole bunch of outfits (and probably is not allowed to name others) that bet the farm on PostgreSQL. :) > Remember that most of the people at a level that can make that > decision have probably barely even heard about PostgreSQL, so it's > no surprise they're not ready to bet the farm on it. Given time and > sucessful deployments in less-critical areas, this will change. > Especially if the big 3 keep their pricing where it is... They may or may not. FOSS databases have cut into their markets in a big way, and we can expect that none of those outfits are going to take it lying down. We've already seen "introductory" pricing, FUD campaigns, etc., and we will doubtless see a lot more as time goes on. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
>> Not only that, but I think the very last answer really hit the nail
>> on the head when it comes to MySQL and PostgreSQL: there's no need
>> to take MySQL's trade-offs for even your light-weight applications.
>
> True.
>
>> The reality is, very few companies are willing to bet their a..erm,
>> donkey ;) on PostgreSQL... yet.
>
> I think this was true two years ago, but just about anybody here can
> name a whole bunch of outfits (and probably is not allowed to name
> others) that bet the farm on PostgreSQL. :)
Shhhhhhhhhhhhh! You will get me in trouble.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote: > > The reality is, very few companies are willing to bet their a..erm, > > donkey ;) on PostgreSQL... yet. > > I think this was true two years ago, but just about anybody here can > name a whole bunch of outfits (and probably is not allowed to name > others) that bet the farm on PostgreSQL. :) My point was that how many fortune 500 companies have mission-critical services that depend on PostgreSQL, especially if they're public-facing? Sure, some have... many more have not. The few that have are on the bleeding edge (which isn't so bloody afterall). In any case, this is rapidly changing. The next few years will certainly be very interesting. :) -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Fri, Oct 13, 2006 at 10:31:14AM -0700, Joshua D. Drake wrote: > Jim C. Nasby wrote: > > On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote: > >>> The reality is, very few companies are willing to bet their a..erm, > >>> donkey ;) on PostgreSQL... yet. > >> I think this was true two years ago, but just about anybody here can > >> name a whole bunch of outfits (and probably is not allowed to name > >> others) that bet the farm on PostgreSQL. :) > > > > My point was that how many fortune 500 companies have > > mission-critical services that depend on PostgreSQL, especially if > > they're public-facing? Sure, some have... many more have not. The few > > that have are on the bleeding edge (which isn't so bloody afterall). > > I find that the fortune 500 companies that are technical in nature are > already running PostgreSQL. Those that are of a different nature likely > aren't. "running PostgreSQL" != "running mission-critical public services on PostgreSQL". :) AFAIK every large customer we've talked to is "running" MySQL... for internal apps that aren't mission-critical. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
> "running PostgreSQL" != "running mission-critical public services on
> PostgreSQL". :)
>
> AFAIK every large customer we've talked to is "running" MySQL... for
> internal apps that aren't mission-critical.
Well any company will to run mysql for mission critical stuff probably
isn't thinking very hard about the implications.
Beyond that, I know of several *technical* based fortune 500 companies
that are doing exactly that... running postgresql on critical
infrastructure. No. I will not name names, don't ask.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Jim C. Nasby wrote: > On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote: >>> The reality is, very few companies are willing to bet their a..erm, >>> donkey ;) on PostgreSQL... yet. >> I think this was true two years ago, but just about anybody here can >> name a whole bunch of outfits (and probably is not allowed to name >> others) that bet the farm on PostgreSQL. :) > > My point was that how many fortune 500 companies have > mission-critical services that depend on PostgreSQL, especially if > they're public-facing? Sure, some have... many more have not. The few > that have are on the bleeding edge (which isn't so bloody afterall). I find that the fortune 500 companies that are technical in nature are already running PostgreSQL. Those that are of a different nature likely aren't. Sincerely, Joshua D. Drake -- SPI Liason, PostgreSQL Fundraising Group Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate Find out about PostgreSQL Fundraising: http://fundraising.postgresql.org/ Read the PostgreSQL docs: http://www.postgresql.org/docs/