Thread: Re: [HACKERS] Enticing interns to PostgreSQL
Jim C. Nasby wrote:
> The email below about FreeBSD's involvement in Google's Summer of Code
> got me thinking; would there be value in trying to attract college
> students to working on either PostgreSQL development, or using
> PostgreSQL in projects? Even though we missed getting in on the summer
> of code this year, ISTM that we could try targeting colleges,
> professors, and students directly. When it comes to development, I'm
> sure there's any number of TODO items that would make great coursework,
> for all different levels of students. As for using PostgreSQL, perhaps
> we could get database classes together with projects that could use
> help.
>
> Thoughts?
>
I am planning to take a database course at a major university this fall.
If you have any materials that might help I'd be happy to see if the
professor is interested. I don't know what the course uses currently,
but I expect there will be opportunities to mention PostgreSQL.
Also, there's a PostgreSQL project that I'm planning on working on (not
even much work left, really), so I'll see if the professor shows any
interest in my project.
Regards,
Jeff Davis
On Wed, Jul 20, 2005 at 03:43:04PM -0700, Jeff Davis wrote: > Jim C. Nasby wrote: > > The email below about FreeBSD's involvement in Google's Summer of Code > > got me thinking; would there be value in trying to attract college > > students to working on either PostgreSQL development, or using > > PostgreSQL in projects? Even though we missed getting in on the summer > > of code this year, ISTM that we could try targeting colleges, > > professors, and students directly. When it comes to development, I'm > > sure there's any number of TODO items that would make great coursework, > > for all different levels of students. As for using PostgreSQL, perhaps > > we could get database classes together with projects that could use > > help. > > > > Thoughts? > > > > I am planning to take a database course at a major university this fall. > If you have any materials that might help I'd be happy to see if the > professor is interested. I don't know what the course uses currently, > but I expect there will be opportunities to mention PostgreSQL. > > Also, there's a PostgreSQL project that I'm planning on working on (not > even much work left, really), so I'll see if the professor shows any > interest in my project. Well, since the typical belief is that MySQL is a good choice for things, http://sql-info.de/mysql/gotchas.html is probably a good start. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Jim C. Nasby wrote: >>Also, there's a PostgreSQL project that I'm planning on working on (not >>even much work left, really), so I'll see if the professor shows any >>interest in my project. > > > Well, since the typical belief is that MySQL is a good choice for > things, http://sql-info.de/mysql/gotchas.html is probably a good start. That's always a great resource. I would be very disappointed, however, if a university professor was using MySQL to teach about relational theory. I'll try to passively raise PostgreSQL awareness when appropriate. Hopefully the professor might take an interest in my project and maybe PostgreSQL will gain awareness among the faculty. Regards, Jeff Davis
On Thu, Jul 21, 2005 at 02:33:22AM -0700, Jeff Davis wrote: > Jim C. Nasby wrote: > >>Also, there's a PostgreSQL project that I'm planning on working on (not > >>even much work left, really), so I'll see if the professor shows any > >>interest in my project. > > > > > > Well, since the typical belief is that MySQL is a good choice for > > things, http://sql-info.de/mysql/gotchas.html is probably a good start. > > That's always a great resource. I would be very disappointed, however, > if a university professor was using MySQL to teach about relational theory. Sadly, I'd be willing to bet there's a lot of professors using MySQL to teach database theory. Just like there's a lot of other people who use it because they don't know any better. But everyone else uses it, so it must be good, right? I fear that MySQL will be a repeat of linux... invest millions (if not billions) in something to finally get it caught up to a better alternative that had been around all along. Why should this matter to PostgreSQL and it's users? Because if MySQL becomes the defacto open source database, that means it will be much more difficult to use PostgreSQL in professional environments, and that many people who might have developed for PostgreSQL will end up developing for MySQL. > I'll try to passively raise PostgreSQL awareness when appropriate. > Hopefully the professor might take an interest in my project and maybe > PostgreSQL will gain awareness among the faculty. Good luck! Hopefully armed with the gotchas you can convince them to not only use PostgreSQL to teach students with, but also to enlighten the students of everything you shouldn't do in a RDBMS. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On 7/22/05, Jim C. Nasby <decibel@decibel.org> wrote: > > Why should this matter to PostgreSQL and it's users? Because if MySQL > becomes the defacto open source database, that means it will be much > more difficult to use PostgreSQL in professional environments, and that > many people who might have developed for PostgreSQL will end up > developing for MySQL. Actually the issue IMHO comes from the business and PR side. This will take a couple paragraphs, indulge me ;-) I see the biggest difference between MySQL<->PostgreSQL is that MySQL has always appeared to be 'owned' by one company, MySQL.com (formerly Monty's company IIRC). PostgreSQL has no such 'owner', so there is no definitive entity to do business with. RedHat almost pulled this off with Linux, but their identity crisis a couple years ago after Robert Young left opened the door for all of the others and RedHat lost their grip. But ultimately that is one thing that holds PostgreSQL back, and other F/OSS projects - when the business world gets involved, they expect someone to be the de-facto source. This is not right or wrong, but reality in the business world, right? Say I am wanting to produce a commercial product, and want to license an open-source database to cash in on the whole open source trend as well as lower costs. I want to have a license, so that I can also use that license as part of the marketing approach to show that this is a 'legitimate' product. With MySQL I can do that, but with PostgreSQL who can I go to? And if I am someone wanting to learn database programming, there are tons of open source databases out there to choose from. Which one do I choose? One factor for me will be the commercial value of my skills that I develop, as if I cannot make money at my trade then this is just a hobby. What I'd love to see for PostgreSQL is a more aggressive push on the business side, to get PostgreSQL into the same enterprise accounts that MySQL is starting to get into. Like Zend is to PHP, who is analogous in the PostgreSQL world? -- Mitch
On Friday 22 July 2005 19:34, Mitch Pirtle wrote:
> On 7/22/05, Jim C. Nasby <decibel@decibel.org> wrote:
> > Why should this matter to PostgreSQL and it's users? Because if MySQL
> > becomes the defacto open source database, that means it will be much
> > more difficult to use PostgreSQL in professional environments, and that
> > many people who might have developed for PostgreSQL will end up
> > developing for MySQL.
>
> Actually the issue IMHO comes from the business and PR side. This will
> take a couple paragraphs, indulge me ;-)
>
> I see the biggest difference between MySQL<->PostgreSQL is that MySQL
> has always appeared to be 'owned' by one company, MySQL.com (formerly
> Monty's company IIRC).
FWIW it has always been owned them. Thats actually one of the reasons that it
got so far ahead of PostgreSQL early on... it wasn't just marketing, it was
that there was always a goal to make a business out of it, increase it's user
base, and to make money from it. The early hackers of PostgreSQL were more
interested in making a quality database for themselves to use than they were
in pushing their product. Even to this day, we have a large number of folks
in influential positions that really see increase of market share as even a
tertiary goal. I'll pick on Afilias for a moment since they are one of the
best companies we have involved in PostgreSQL... their goal (imho) wrt is not
to increase PostgreSQL market share, but to increase their ability to achieve
"world domination" in the registry services business, which is the business
they are in. If PostgreSQL market share increases, they realize that is a
good thing for them, and so they have helped support the projects efforts to
get more users, but in the end it's not their end goal in the least, so it's
not something their people focus on.
> PostgreSQL has no such 'owner', so there is no
> definitive entity to do business with. RedHat almost pulled this off
> with Linux, but their identity crisis a couple years ago after Robert
> Young left opened the door for all of the others and RedHat lost their
> grip.
>
> But ultimately that is one thing that holds PostgreSQL back, and other
> F/OSS projects - when the business world gets involved, they expect
> someone to be the de-facto source. This is not right or wrong, but
> reality in the business world, right?
>
Well, I would say they certainly want someone to be a defacto source, though
it doesn't necessarily need to be an "owner" per say. Think Red Hat or
Novell and Linux, they don't own it, but they are the defacto players when
you want to do platform partnering.
> Say I am wanting to produce a commercial product, and want to license
> an open-source database to cash in on the whole open source trend as
> well as lower costs. I want to have a license, so that I can also use
> that license as part of the marketing approach to show that this is a
> 'legitimate' product. With MySQL I can do that, but with PostgreSQL
> who can I go to?
>
There are places you *could* go, but they aren't the same as going to my$ql
inc.
> And if I am someone wanting to learn database programming, there are
> tons of open source databases out there to choose from. Which one do I
> choose? One factor for me will be the commercial value of my skills
> that I develop, as if I cannot make money at my trade then this is
> just a hobby.
>
If you are really concerned about this, you would probably download one of the
free developers installs of the proprietary db companies. :-) But your point
is valid... and has been raised before, usually in the realm of things like
"how do i get certified?". SRA has started a program, but I wonder what the
demand has been from folks outside the community, because I feel it is not
nearly as large as some inside the community would have you believe.
> What I'd love to see for PostgreSQL is a more aggressive push on the
> business side, to get PostgreSQL into the same enterprise accounts
> that MySQL is starting to get into. Like Zend is to PHP, who is
> analogous in the PostgreSQL world?
IMO I would say the most "zend like" company in the pg community right now is
Command Prompt, who have been ratcheting up their involvement within the
community over the last 6 months - 1 year. The caveat here is that unlike
zend, they have a lot of big companies lurking about that are also players in
the pg community (sra,fujitsu,pervasive,redhat) that could make very big
moves if pointed in the right direction. It also remains to be seen just
what impact enterprisedb and greenplum on this picture; these companies are
much more business focused, but not exactly focused on pg.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>>What I'd love to see for PostgreSQL is a more aggressive push on the >>business side, to get PostgreSQL into the same enterprise accounts >>that MySQL is starting to get into. Like Zend is to PHP, who is >>analogous in the PostgreSQL world? > > > IMO I would say the most "zend like" company in the pg community right now is > Command Prompt, who have been ratcheting up their involvement within the > community over the last 6 months - 1 year. The caveat here is that unlike > zend, they have a lot of big companies lurking about that are also players in > the pg community (sra,fujitsu,pervasive,redhat) that could make very big > moves if pointed in the right direction. Also, unlike Zend there is a benefit to the continual cooperative competition that SRA, Fugitsu etc... have with the community and Command Prompt. For example, SRA and Command Prompt are responsible for the PostgreSQL.Org booth this year at OSCON. I think in the long run everyone will still exist just like most Linux distributions still exist but more and more they will specialize in specific departments. For example, Command Prompt is probably the most infrastructure focused of the PostgreSQL companies where someone like Fujitsu focuses more on serving and existing customer base with a modified version of PostgreSQL. Pervasive will have their hands full as all there legacy customers come do and (I assume) that they start moving to Pervasive PostgreSQL. In all, I think you would be amazed at how aggressive PostgreSQL is on the business side, we (the community) just do it differently than a lot of traditional companies. We have a lot of word of mouth, a lot of the consultants and companies look out for each other, warning of potential bad customers etc... We also cooperate to publicize PostgreSQL as a whole. We don't in general run a lot of press, but then again we typically don't have to. Sincerely, Joshua D. Drake It also remains to be seen just > what impact enterprisedb and greenplum on this picture; these companies are > much more business focused, but not exactly focused on pg. > -- Your PostgreSQL solutions provider, Command Prompt, Inc. 24x7 support - 1.800.492.2240, programming, and consulting Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit http://www.commandprompt.com / http://www.postgresql.org
Hi, Mitch Pirtle wrote: > > What I'd love to see for PostgreSQL is a more aggressive push on the > business side, to get PostgreSQL into the same enterprise accounts > that MySQL is starting to get into. Like Zend is to PHP, who is > analogous in the PostgreSQL world? I'd hate to see the analog of Zend in PostgreSQL world. Zend's business model is beneficial for them, but bad for PHP community. The classic example is absence of bytecode compilation (available in all other major scripting languages) in default PHP. To get this you need to pay money to Zend for Super Advanced Zend Enterprise Ready Accelerator Platform Plus, or whatever the thing is called now. The guys have a sh*tload of engine level bugs in the language and refuse to fix them, but have a lot of money spent on PR and "enterprise" cruft they are marketing. Maybe Zend is making inroads into the enterprise, but they are damaging their ecosystem in the process, by alienating the developers [1] that are building the major Open Source applications in and around PHP. And these applications are what drives most people to PHP, not "Super Advanced Zend Enterprise Ready Accelerator Platform Plus". So "having Zend in PostgreSQL world" translates to me as "keeping PostgreSQL substandard product to be able to sell addons for it". I doubt that is a good idea. [1] http://www.sitepoint.com/forums/showthread.php?t=279833
On Fri, Jul 22, 2005 at 17:47:09 -0500, "Jim C. Nasby" <decibel@decibel.org> wrote: > > Sadly, I'd be willing to bet there's a lot of professors using MySQL to > teach database theory. Just like there's a lot of other people who use > it because they don't know any better. But everyone else uses it, so it > must be good, right? I don't see a problem for the professors or students using MySQL to learn database theory. For a first course in database theory you could use almost anything to practice issuing some DDL and DML commands. It might be nice PR for Postgres to have professors using that instead of MySQL. So as a Postgres developer or user you might not like this, but its not as if the students are going to be scarred for life by using MySQL to practice creating tables and doing simple queries. > I fear that MySQL will be a repeat of linux... invest millions (if not > billions) in something to finally get it caught up to a better > alternative that had been around all along. What great alternative to Linux do you think there was when Linus started working on it? Free versions of BSD came out while Linux was still pretty raw, but they had issues of their own. It might have been better to take up a collection to free some existing OS, but that wasn't likely to happen at that time. > Why should this matter to PostgreSQL and it's users? Because if MySQL > becomes the defacto open source database, that means it will be much > more difficult to use PostgreSQL in professional environments, and that > many people who might have developed for PostgreSQL will end up > developing for MySQL. That seems unlikely to happen with the owners of MySQL threatening users with money to cough some up or risk being sued. I don't think the open source database market is going to be reduced to effectively one system any time soon. The main problem I see is that some applications have been developed such that they are tied to MySQL (either form using its quirks extensively or being designed so that performance sucks on other databases) so that we are stuck running some MySQL servers to run these applications. However just because we run them to support specific applications (e.g. Horde), doesn't mean we need or want to develop are own applications using MySQL.
On Fri, Jul 22, 2005 at 19:34:57 -0400, Mitch Pirtle <mitch.pirtle@gmail.com> wrote: > > I see the biggest difference between MySQL<->PostgreSQL is that MySQL > has always appeared to be 'owned' by one company, MySQL.com (formerly > Monty's company IIRC). PostgreSQL has no such 'owner', so there is no > definitive entity to do business with. RedHat almost pulled this off > with Linux, but their identity crisis a couple years ago after Robert > Young left opened the door for all of the others and RedHat lost their > grip. I don't think Redhat was ever much of a threat to control Linux. Unlike mysql.com they don't hold the copyright to Linux and couldn't dual license it the way mysql.com can. They may have been more dominent in the commercial Linux distribution market, but there would have been competing distributions.
On Sat, Jul 23, 2005 at 08:41:07AM -0500, Bruno Wolff III wrote: > I don't see a problem for the professors or students using MySQL to learn > database theory. For a first course in database theory you could use > almost anything to practice issuing some DDL and DML commands. > > It might be nice PR for Postgres to have professors using that instead > of MySQL. So as a Postgres developer or user you might not like this, > but its not as if the students are going to be scarred for life by > using MySQL to practice creating tables and doing simple queries. The problem is that not only does MySQL tend to shun ANSI SQL (think concat v. ||), but it also does a lot of things no real database would ever do, such as silently truncating data, or allowing count(*) to return an estimate instead of an actual rowcount. These (and other) 'MySQLisms' would certainly end up in any class, and it would be very easy for students to think "Oh, this is just how databases are supposed to work." > What great alternative to Linux do you think there was when Linus started > working on it? Free versions of BSD came out while Linux was still pretty > raw, but they had issues of their own. It might have been better to take > up a collection to free some existing OS, but that wasn't likely to happen > at that time. IIRC, FreeBSD (or maybe only NetBSD) was readily available at the time Linas wrote Linux, there were just some licensing questions. This would obviously be an issue for commercial use, but not really for personal use. But, that's really neither here nor there; my point is that linux (like MySQL) was for a very long time significantly inferior to the *BSD's. The only advantage it offered was it would run on cheap hardware. For a long time it was largely (and perhaps rightfully) poo-poo'd by FreeBSD developers. Now, FreeBSD (the largest of the BSDs) can only dream of having the amount of development effort available to linux, even including all the work that Apple is putting into BSD and Darwin. > > Why should this matter to PostgreSQL and it's users? Because if MySQL > > becomes the defacto open source database, that means it will be much > > more difficult to use PostgreSQL in professional environments, and that > > many people who might have developed for PostgreSQL will end up > > developing for MySQL. > > That seems unlikely to happen with the owners of MySQL threatening users > with money to cough some up or risk being sued. We can always hope they eat the goose that laid their golden egg... :) > I don't think the open source database market is going to be reduced to > effectively one system any time soon. Soon? No. But I strongly suspect that given the current situation, MySQL will eventually be the defacto OSS database, just as linux has become the defacto OSS OS. This is already happening despite all it's technical flaws, and will only get worse as those flaws get 'fixed'. > The main problem I see is that some applications have been developed such > that they are tied to MySQL (either form using its quirks extensively or > being designed so that performance sucks on other databases) so that we > are stuck running some MySQL servers to run these applications. However > just because we run them to support specific applications (e.g. Horde), > doesn't mean we need or want to develop are own applications using > MySQL. This is a perfect example of why MySQL could end up as the linux of databases. People write applications that depend on MySQL because it's 'what everyone else does'. They don't use any kind of abstraction layer because it's 'what everyone else does'. And they don't understand things like why ACID is important, because 'nobody else does'. I've run into numerous people who are 'stuck' with MySQL, because it's too hard to migrate. As one person recently put it, "I wish MySQL sucked more, because then it would be easy to decide to migrate. But it's just barely OK for what we need, so we stick with it." Fortunately, word is slowly getting around that PostgreSQL is better than MySQL, but I suspect it's too little too late. While I expect MySQL 5.0 to still suffer from serious flaws, it will remove a lot of the shortcommings that are easy to point out and easy to understand why they're so bad. This makes it more and more difficult to convince people that PostgreSQL is a better choice, because people love to follow the herd. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
> I'd hate to see the analog of Zend in PostgreSQL world. > > Zend's business model is beneficial for them, but bad for PHP community. > The classic example is absence of bytecode compilation (available in all > other major scripting languages) in default PHP. To get this you need to > pay money to Zend for Super Advanced Zend Enterprise Ready Accelerator No you don't. PHP is BSD style licensed just like PostgreSQL. If you want Super Advanced Zend Enterprise Ready Accelerator and don't want to pay for it, you can create your own and several already have. > Platform Plus, or whatever the thing is called now. The guys have a > sh*tload of engine level bugs in the language and refuse to fix them, Again BSD style license, anyone can jump in at any time and fix them. > Maybe Zend is making inroads into the enterprise, but they are damaging > their ecosystem in the process, by alienating the developers [1] that > are building the major Open Source applications in and around PHP. How are they damaging "their" ecosystem. It isn't "their" ecosystem, it is the PHP communities, Zend is just one (albeit powerful within the community) member. If people were truly unhappy with the direction of PHP somebody would fork it, fix it, and create PHP++. The unfortunate part is that most PHP programmers don't care or don't have the skills required to fix the problems. I am not saying Zend is a good or bad company, I honestly don't know but your arguments don't make sense to me. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions provider, Command Prompt, Inc. 24x7 support - 1.800.492.2240, programming, and consulting Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit http://www.commandprompt.com / http://www.postgresql.org
On Fri, Jul 22, 2005 at 07:34:57PM -0400, Mitch Pirtle wrote: > Say I am wanting to produce a commercial product, and want to license > an open-source database to cash in on the whole open source trend as > well as lower costs. I want to have a license, so that I can also use > that license as part of the marketing approach to show that this is a > 'legitimate' product. With MySQL I can do that, but with PostgreSQL > who can I go to? In this example, I believe there is a legal entity that owns the PostgreSQL license, so that's who you would go to. Though that entity isn't very well advertised... Of course, this example is pretty pointless because the whole purpose behind the BSD license is that you can do whatever you want with PostgreSQL (unlike MySQL). > And if I am someone wanting to learn database programming, there are > tons of open source databases out there to choose from. Which one do I > choose? One factor for me will be the commercial value of my skills > that I develop, as if I cannot make money at my trade then this is > just a hobby. I suspect that PostgreSQL contractors make more money than MySQL ones. And Oracle ones certainly make even more still. > What I'd love to see for PostgreSQL is a more aggressive push on the > business side, to get PostgreSQL into the same enterprise accounts > that MySQL is starting to get into. Like Zend is to PHP, who is > analogous in the PostgreSQL world? Well, that's part of what many of the commercial companies with some form of a PostgreSQL offering hope to do. EnterpriseDB is a good example; their Oracle compatability is clearly targeted at large business users. But the problem is that grassroots OSS movements change the market once they get large enough. 10, or even 5 years ago it was impossible to get linux into big business, for many of the reasons you mentioned. But that's changed, even though *BSD was technically superior. It changed because there was a virtual army of linux users who wanted very badly to be able to use linux at work. MySQL has more 'foot-soldiers' than PostgreSQL does, even if a lot of them are alienated. I think we need to do 2 things to ensure PostgreSQL doesn't get relegated to niche status. First, we need to counter MySQL's FUD. MySQL has a laundry-list of 'companies that are using mysql', even though it doesn't mean anything more than they've got it sitting on a server somewhere. Of course there's also they're misrepresentive benchmarks. Second (and probably more important), we need to make it easier for people to migrate to PostgreSQL from MySQL. There's a sizeable number of people who would like to migrate things off of MySQL if it wasn't so difficult, and hard to do incrementally. Adding support for some MySQL features (such as enum and tinyint), making it easy for PostgreSQL databases to talk to MySQL databases (perhaps via dblink), and providing methods to connect to PostgreSQL without having to tear out big chunks of un-abstracted code are some things that would help here. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Fri, Jul 22, 2005 at 10:04:42PM -0700, Joshua D. Drake wrote: > In all, I think you would be amazed at how aggressive PostgreSQL is on > the business side, we (the community) just do it differently than a lot > of traditional companies. > > We have a lot of word of mouth, a lot of the consultants and companies > look out for each other, warning of potential bad customers etc... We > also cooperate to publicize PostgreSQL as a whole. > > We don't in general run a lot of press, but then again we typically > don't have to. One problem with that is: where do people go when they want to find out about PostgreSQL and MySQL? To the websites. Currently, MySQL has 1/4 of their front page dedicated to "Discover how Global 2000 companies are cutting their database costs by 90%". And "Over six million installations use MySQL to power high-volume Web sites and other critical business systems — including industry-leaders like The Associated Press, Yahoo, NASA, Sabre Holdings and Suzuki." Our site has nothing like that. If you dig into the websites, it just gets worse. http://mysql.com/industry/: "Cox Communications powers massive data warehouse with MySQL." The custormer's page lists over 100 entries. Case studies, white papers, etc. Of course it's easy for a commercial company to hire a full-time MarCom person (or team), but given the number of commercial companies supporting PostgreSQL we should be able to do just as good a job at messaging, if not better. Heck, I bet even the 'small' companies supporting PostgreSQL together are larger than MySQL AB, let alone companies like Fujitsu. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
> > One problem with that is: where do people go when they want to find out > about PostgreSQL and MySQL? To the websites. Currently, MySQL has 1/4 of > their front page dedicated to "Discover how Global 2000 companies are > cutting their database costs by 90%". And "Over six million MySQL is a company. PostgreSQL is not. We will never as a community be able to compete with MySQL as a company. It is not the job of the community to **market**, advocate yes, market no. It is the job of the commercial entities such as Command Prompt, SRA, GreenPlum, Pervasive and PgSQL, Inc. to do marketing. > installations use MySQL to power high-volume Web sites and other > critical business systems — including industry-leaders like The > Associated Press, Yahoo, NASA, Sabre Holdings and Suzuki." Our site has > nothing like that. Neither does Linux.Org, but Redhat and Novell do. > Of course it's easy for a commercial company to hire a full-time MarCom > person (or team), but given the number of commercial companies > supporting PostgreSQL we should be able to do just as good a job at > messaging, if not better. Heck, I bet even the 'small' companies > supporting PostgreSQL together are larger than MySQL AB, let alone > companies like Fujitsu. This if I recall is what the PostgreSQL Foundation is for. It should also be noted that companies are marketing more and more with PostgreSQL. Look at the press that EnterpriseDB has gotten. Heck even Greenplum and Command Prompt have been picked up recently without Command Prompt (I don't know about Greenplum) doing anything to solicit the pick up. In a way I prefer the PostgreSQL marketing because the MySQL marketing is just that... All the press they get isn't press seeking them out, it is MySQL seeking out the press, soliciting interviews, whitepapers etc... Why doesn't the press (for the most part) do that with PostgreSQL? Because PostgreSQL is not a commercial entity. PostgreSQL is not an advertiser. PostgreSQL is just another Open Source project. Everytime PostgreSQL gets picked up by the press it is because of the general work and quality of the PostgreSQL product. Most of the time that MySQL gets picked up it is because somebody in a tie, called another guy in a tie, who forced some poor journalist to write about something he really has no clue about, just to spout FUD about everybody BUT MySQL. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions provider, Command Prompt, Inc. 24x7 support - 1.800.492.2240, programming, and consulting Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit http://www.commandprompt.com / http://www.postgresql.org
On Saturday 23 July 2005 12:43, Jim C. Nasby wrote:
> I think we need to do 2 things to ensure PostgreSQL doesn't get
> relegated to niche status.
as a side question, do you feel BSD is a niche operating system?
> First, we need to counter MySQL's FUD. MySQL
> has a laundry-list of 'companies that are using mysql', even though it
> doesn't mean anything more than they've got it sitting on a server
> somewhere. Of course there's also they're misrepresentive benchmarks.
>
pgsql inc has something like this, a registered users site (or at least they
used to). I have on my todo to convert that into something for the main www
site, but it's gonna be awhile before I get to it. Of course if anyone is
interested in picking it up, shoot me an email.
(BTW, calling the my$ql customer list FUD is rather harsh, afaik all of the
companies listed there are customers of my$ql, and the oss projects do
support my$ql.)
> Second (and probably more important), we need to make it easier for
> people to migrate to PostgreSQL from MySQL. There's a sizeable number of
> people who would like to migrate things off of MySQL if it wasn't so
> difficult, and hard to do incrementally. Adding support for some MySQL
> features (such as enum and tinyint), making it easy for PostgreSQL
> databases to talk to MySQL databases (perhaps via dblink), and providing
> methods to connect to PostgreSQL without having to tear out big chunks
> of un-abstracted code are some things that would help here.
I always get concerned when things devolve into a pg vs my$ql scenario. What
I think we need to do is make it easier for people to convert from $ql $erver
and oracle to postgresql. They have larger user bases and have folks willing
to pay for development/support. If we can make it simple enough that 50% of
the people using my$ql all switch to postgres, but my$ql goes after the
corporations and gets 50% of them to switch to my$ql, were not going to come
out on top.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Hi, Joshua D. Drake wrote: >> Zend's business model is beneficial for them, but bad for PHP >> community. The classic example is absence of bytecode compilation >> (available in all other major scripting languages) in default PHP. To >> get this you need to pay money to Zend for Super Advanced Zend >> Enterprise Ready Accelerator > > No you don't. PHP is BSD style licensed just like PostgreSQL. If you > want Super Advanced Zend Enterprise Ready Accelerator and don't want to > pay for it, you can create your own and several already have. First of all, PHP is two parts: there is language itself licensed under BSD-like license and there is Zend engine (virtual machine running the bytecode) licensed under QPL-like license. Which essentially means that commercial "forks" of PHP are feasible only if you use some other virtual machine. This is a huge difference to pure-BSD PostgreSQL with its multiple forks. Of course I know about existing accelerators, but they are third party addons, in other languages this is built-in feature. Why does Command Prompt sell *integrated* replication solution? >> Platform Plus, or whatever the thing is called now. The guys have a >> sh*tload of engine level bugs in the language and refuse to fix them, > > Again BSD style license, anyone can jump in at any time and fix them. Ah, the classic line: send in the patches. The Ultimate Open Source Argument That Should Make The Opponent Shut Up Immediately And Crawl Away. My point was that Zend employs the best experts on PHP internals but these experts are busy doing stuff that brings money. >> Maybe Zend is making inroads into the enterprise, but they are >> damaging their ecosystem in the process, by alienating the developers >> [1] that are building the major Open Source applications in and around >> PHP. > > How are they damaging "their" ecosystem. It isn't "their" ecosystem, it > is the PHP communities, Zend is just one (albeit powerful within the > community) member. > > If people were truly unhappy with the direction of PHP somebody would > fork it, fix it, and create PHP++. See above. There is (was?) a project to run PHP on Parrot virtual machine, that may even some day become your PHP++. > The unfortunate part is that most PHP programmers don't care or don't > have the skills required to fix the problems. The unfortunate part is that most Java programmers don't care or don't have the skills required to fix bugs in a Java virtual machine. The unfortunate part is that most DBMS administrators don't care or don't have the skills required to fix bugs in their DBMS. Er, what was your point, again? > I am not saying Zend is a good or bad company, I honestly don't know but > your arguments don't make sense to me. OK, once again: though PHP-the-language is BSD-like licensed, there is a crucial part of infrastructure needed to run it which is owned by a company. And this company obviously cares more about selling their products than about making the language they depend upon better. Why give something for free when you can sell it? To sum it up: a) Zend example does not apply to PostgreSQL for reasons described above; b) Even if it did apply, that's hardly an example we'd like to follow.
On Sat, Jul 23, 2005 at 11:19:26AM -0700, Joshua D. Drake wrote:
> Most of the time that MySQL gets picked up it is because somebody in a
> tie, called another guy in a tie, who forced some poor journalist to
> write about something he really has no clue about, just to spout FUD
> about everybody BUT MySQL.
And you don't think that's worth countering?
Yes, PostgreSQL isn't technically a company. But the fact remains that
when people look at both websites, they see a whole bunch of success
stories about MySQL on their site, and next to nothing of the kind on
the PostgreSQL site. I find it hard to believe that this doesn't make
MySQL look like a better choice ("Wow, look at all these companies that
are using it!")
Understand that I'm not suggesting changes to the community, or even
legal entites. What I'm saying is that while it's good that individual
companies are getting press about their PostgreSQL offerings, there's
not really anything that makes it easy for people to see that. Putting
case studies from these individual companies on http://postgresql.org
would be a good start towards fixing this. Publishing prominent
customers would help as well.
Put another way, MySQL is making a well planned, coordinated effort to
gain market share as an OSS database. PostgreSQL has no such effort, and
without it I believe it's headed down the road to eventual obscurity.
Yet if there was some cooperation between the community and the numerous
commercial companies, the message of PostgreSQL, and why it's actually
*better* than MySQL, would be out there for everyone to see.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
On Sat, Jul 23, 2005 at 02:27:51PM -0400, Robert Treat wrote: > On Saturday 23 July 2005 12:43, Jim C. Nasby wrote: > > I think we need to do 2 things to ensure PostgreSQL doesn't get > > relegated to niche status. > > as a side question, do you feel BSD is a niche operating system? All things considered, yes. This is especially true outside of ISP's. But, there's something even more important than userbase, and that's development effort. I think it's pretty easy to see that linux is clearly ahead of *BSD there. > > First, we need to counter MySQL's FUD. MySQL > > has a laundry-list of 'companies that are using mysql', even though it > > doesn't mean anything more than they've got it sitting on a server > > somewhere. Of course there's also they're misrepresentive benchmarks. > > > > pgsql inc has something like this, a registered users site (or at least they > used to). I have on my todo to convert that into something for the main www > site, but it's gonna be awhile before I get to it. Of course if anyone is > interested in picking it up, shoot me an email. Maybe put the code in pg-foundry so it's easy for people to help? > (BTW, calling the my$ql customer list FUD is rather harsh, afaik all of the > companies listed there are customers of my$ql, and the oss projects do > support my$ql.) I didn't mean that the customer list was FUD (even though it came across that way). What is FUD is a lot of their benchmarks, etc. that show them to be superior to other databases. There is also a lot of FUD around MySQL in the OSS community. I've actually seen websites *apologize* for using PostgreSQL (since they needed minor features like subqueries and views). > > Second (and probably more important), we need to make it easier for > > people to migrate to PostgreSQL from MySQL. There's a sizeable number of > > people who would like to migrate things off of MySQL if it wasn't so > > difficult, and hard to do incrementally. Adding support for some MySQL > > features (such as enum and tinyint), making it easy for PostgreSQL > > databases to talk to MySQL databases (perhaps via dblink), and providing > > methods to connect to PostgreSQL without having to tear out big chunks > > of un-abstracted code are some things that would help here. > > I always get concerned when things devolve into a pg vs my$ql scenario. What > I think we need to do is make it easier for people to convert from $ql $erver > and oracle to postgresql. They have larger user bases and have folks willing > to pay for development/support. If we can make it simple enough that 50% of > the people using my$ql all switch to postgres, but my$ql goes after the > corporations and gets 50% of them to switch to my$ql, were not going to come > out on top. I absolutely agree that we should be assisting in the migration from Oracle and MSSQL, but there's already a good amount of focus on that (as well there should be). But I think it's also folly not to promote MySQL->PostgreSQL migration. The only advantage MySQL has over PostgreSQL is the size of the user community. More users means more tools means more apps written for MySQL means more users, etc. Many times people start off on MySQL then find themselves wishing they hadn't once they get some exposure to PostgreSQL. Yet they stay with MySQL because of how difficult it would be to migrate. So they stay MySQL users, giving MySQL more momentum. Fortunately, since MySQL is a fairly simple database, it wouldn't be too difficult to offer features that would greatly ease migration. Even some simple things like providing an equivalent to enum would probably go a long way. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Saturday 23 July 2005 16:15, Jim C. Nasby wrote:
> On Sat, Jul 23, 2005 at 02:27:51PM -0400, Robert Treat wrote:
> > On Saturday 23 July 2005 12:43, Jim C. Nasby wrote:
> > > I think we need to do 2 things to ensure PostgreSQL doesn't get
> > > relegated to niche status.
> >
> > as a side question, do you feel BSD is a niche operating system?
>
> All things considered, yes. This is especially true outside of ISP's.
> But, there's something even more important than userbase, and that's
> development effort. I think it's pretty easy to see that linux is
> clearly ahead of *BSD there.
Ah, but this is one of the advantages we have over my$ql that bsd did not have
over linux, which is that we are able to better harness the development
efforts of our community than my$ql is. Between the GPL license, and more
importantly the tight copyright controls around the my$ql code base, it just
isn't feasible for companies to jump in and extend thier system. That
development has to be done in house, but with us it can be done from any
number of sources. This isn't that bsd doesnt have these aspects, but linux
had them as well, so there was no advantage there. In the long run we have a
big advantage over my$ql in this area.
>
> > > First, we need to counter MySQL's FUD. MySQL
> > > has a laundry-list of 'companies that are using mysql', even though it
> > > doesn't mean anything more than they've got it sitting on a server
> > > somewhere. Of course there's also they're misrepresentive benchmarks.
> >
> > pgsql inc has something like this, a registered users site (or at least
> > they used to). I have on my todo to convert that into something for the
> > main www site, but it's gonna be awhile before I get to it. Of course if
> > anyone is interested in picking it up, shoot me an email.
>
> Maybe put the code in pg-foundry so it's easy for people to help?
>
Heh, let's rehash this again eh? The code is on gborg, there is even a
question in the FAQ pointing people to the project and mailing lists for
people who are interested in contributing.
>
> > > Second (and probably more important), we need to make it easier for
> > > people to migrate to PostgreSQL from MySQL. There's a sizeable number
> > > of people who would like to migrate things off of MySQL if it wasn't so
> > > difficult, and hard to do incrementally. Adding support for some MySQL
> > > features (such as enum and tinyint), making it easy for PostgreSQL
> > > databases to talk to MySQL databases (perhaps via dblink), and
> > > providing methods to connect to PostgreSQL without having to tear out
> > > big chunks of un-abstracted code are some things that would help here.
> >
> > I always get concerned when things devolve into a pg vs my$ql scenario.
> > What I think we need to do is make it easier for people to convert from
> > $ql $erver and oracle to postgresql. They have larger user bases and
> > have folks willing to pay for development/support. If we can make it
> > simple enough that 50% of the people using my$ql all switch to postgres,
> > but my$ql goes after the corporations and gets 50% of them to switch to
> > my$ql, were not going to come out on top.
>
> I absolutely agree that we should be assisting in the migration from
> Oracle and MSSQL, but there's already a good amount of focus on that (as
> well there should be).
>
> But I think it's also folly not to promote MySQL->PostgreSQL migration.
> The only advantage MySQL has over PostgreSQL is the size of the user
> community. More users means more tools means more apps written for MySQL
> means more users, etc. Many times people start off on MySQL then find
> themselves wishing they hadn't once they get some exposure to
> PostgreSQL. Yet they stay with MySQL because of how difficult it would
> be to migrate. So they stay MySQL users, giving MySQL more momentum.
>
I'm not saying we don't want people to convert, but if the end goal is to
increase the user base, why go after a small piece of the pie? I think that
the $ql$erver/oracle user bases are signifigantly larger than my$qls that it
offsets an ease of convincing that you might have when dealing with my$ql
users.
> Fortunately, since MySQL is a fairly simple database, it wouldn't be
> too difficult to offer features that would greatly ease migration. Even
> some simple things like providing an equivalent to enum would probably
> go a long way.
I can see why people like enum, but its just not a sound way to do things.
It's kind of like how they do timestamps, sure its handy in some scenarios,
but just dumb in others. I don't think your ever going to see these features
put into mainline postgresql. Maybe you can get enterprisedb to code up a
"uppsala" mode, but outside of that I think you'd just be better off making a
website listing specific my$ql features, why people find fault in them, and
then how to work around them in pg.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> Put another way, MySQL is making a well planned, coordinated effort to > gain market share as an OSS database. PostgreSQL has no such effort, and > without it I believe it's headed down the road to eventual obscurity. > Yet if there was some cooperation between the community and the numerous > commercial companies, the message of PostgreSQL, and why it's actually > *better* than MySQL, would be out there for everyone to see. See this is where I think you are incorrect. There is an effort a very concerted effort brought on by the commercial entities backing PostgreSQL. I just had this conversation with a potential customer. They are leaving Oracle due to costs, and were considering PostgreSQL. One of their **ahem** executives felt that MSSQL might be a good choice because there wasn't any "enterprise" users of PostgreSQL. I shot back the list of enterprise customers that Command Prompt has AND the list of enterprise customers that the community has. I don't think there will be a problem :) Sincerely, Joshua D. Drake -- Your PostgreSQL solutions provider, Command Prompt, Inc. 24x7 support - 1.800.492.2240, programming, and consulting Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit http://www.commandprompt.com / http://www.postgresql.org
Bruno Wolff III wrote:
> On Fri, Jul 22, 2005 at 17:47:09 -0500,
> "Jim C. Nasby" <decibel@decibel.org> wrote:
>
>>Sadly, I'd be willing to bet there's a lot of professors using MySQL to
>>teach database theory. Just like there's a lot of other people who use
>>it because they don't know any better. But everyone else uses it, so it
>>must be good, right?
>
>
> I don't see a problem for the professors or students using MySQL to learn
> database theory. For a first course in database theory you could use
> almost anything to practice issuing some DDL and DML commands.
>
> It might be nice PR for Postgres to have professors using that instead
> of MySQL. So as a Postgres developer or user you might not like this,
> but its not as if the students are going to be scarred for life by
> using MySQL to practice creating tables and doing simple queries.
>
>
I disagree. In MySQL, it often silently ignores errors, and has strange
behavior. Dates are a perfect example: it thinks Feb 31st can go in a
date column. And you can't create your own types.
Basically, it reduces the database to a place to throw data and get it
back a little later. Everything else is client-side processing
(including all detection and recovery for malformed data coming out of
the database). That very easily could cause serious misconceptions about
the role of a relational database management system.
By the way, this is a university level class, not vocational school. I
would be disappointed if they spent all the time learning SQL and
practicing commands.
Here is the class description (UCSD):
CSE132A Database System Principles
"Basic concepts of databases including data modeling,
relational databases, query languages, optimization,
dependencies, schema design, and concurrency con-
trol. Exposure to one or several commercial database
systems. Advanced topics such as deductive and
object-oriented databases, time allowing."
So, back on the subject, does someone see a good advocacy opportunity
here? I think many students would be able to help if we devised some
ways to advocate PostgreSQL in that kind of environment without
distracting from the main topics in the course.
Basically, here's what I've got so far:
(1) Make passive comments about PostgreSQL when appropriate, and mention
the name "PostgreSQL". For example, if the professor asks a question
that could be answered by "the PostgreSQL way".
(2) I started work on a project a while ago to improve concurrent
seqential scans of the same table. It works, but it needs testing and
needs to be better integrated with PostgreSQL source conventions. I'll
mention it to the professor and see if he's interested in helping me. If
so, he's bound to gain some real respect for PostgreSQL.
Regards,
Jeff Davis
Folks, > > Sadly, I'd be willing to bet there's a lot of professors using MySQL to > > teach database theory. Just like there's a lot of other people who use > > it because they don't know any better. But everyone else uses it, so it > > must be good, right? In my experience, universities in the US tend to use one of 3 database systems to teach DB programming: 1) Oracle because the Uni has a campus-wide license and there's lots of good books on Oracle. 2) MS SQL Server because the Uni is an all-Microsoft shop 3) PostgreSQL because they can take it apart I can't say that I've encountered MySQL being used for University courses from anyone I've talked to at conventions. Also, shouldn't we be discussing this on -Advocacy, not -Hackers? -- Josh Berkus Aglio Database Solutions San Francisco
On Sun, 2005-07-24 at 21:19, Josh Berkus wrote:
> Folks,
>
> > > Sadly, I'd be willing to bet there's a lot of professors using MySQL to
> > > teach database theory. Just like there's a lot of other people who use
> > > it because they don't know any better. But everyone else uses it, so it
> > > must be good, right?
>
> In my experience, universities in the US tend to use one of 3 database systems
> to teach DB programming:
>
> 1) Oracle because the Uni has a campus-wide license and there's lots of good
> books on Oracle.
> 2) MS SQL Server because the Uni is an all-Microsoft shop
> 3) PostgreSQL because they can take it apart
>
I'd certainly agree on 1 & 2, though I haven't seen widespread examples
of 3. As Fabian Pascal likes to say, most universities are more
interested in teaching about products than teching fundamentals, so they
don't have much need for a database you can take apart.
> I can't say that I've encountered MySQL being used for University courses from
> anyone I've talked to at conventions.
>
You'd be surprised then. A co-worker recently went through some online
courses at the university of kansas. For his database classes they used
oracle/java, but for web development classes, they also used my$ql/php.
I imagine this scenario is pretty common, where you cant use my$ql for
any real db class because it just doesnt have the feature set, but in
web development classes where you dont care about your data store, and
want something simple for windows users to install on thier own
machines, my$ql would be an obvious choice.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Sat, Jul 23, 2005 at 02:06:54PM -0700, Joshua D. Drake wrote: > > >Put another way, MySQL is making a well planned, coordinated effort to > >gain market share as an OSS database. PostgreSQL has no such effort, and > >without it I believe it's headed down the road to eventual obscurity. > >Yet if there was some cooperation between the community and the numerous > >commercial companies, the message of PostgreSQL, and why it's actually > >*better* than MySQL, would be out there for everyone to see. > > See this is where I think you are incorrect. There is an effort a very > concerted effort brought on by the commercial entities backing PostgreSQL. > > I just had this conversation with a potential customer. They are leaving > Oracle due to costs, and were considering PostgreSQL. One of their > **ahem** executives felt that MSSQL might be a good choice because there > wasn't any "enterprise" users of PostgreSQL. > > I shot back the list of enterprise customers that Command Prompt has AND > the list of enterprise customers that the community has. > > I don't think there will be a problem :) Yes, but the difference is that MySQL has that info plastered all over it's website. Any exec visiting their site would have to be blind to miss it. But when they visit the PostgreSQL site, they'll find very little info about companies that are using PostgreSQL, and there's nothing that obviously points out that unlike MySQL, PostgreSQL isn't a company, but here's a list of the companies that provide commercial services for PostgreSQL. In addition to those interested in commercial support, having things like a list of customers on the MySQL site makes it look like they have far more commercial users than PostgreSQL does; something that might well not be the case. This contributes to newbies thinking that MySQL must be a better choice to use. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Sat, Jul 23, 2005 at 02:28:01PM -0700, Jeff Davis wrote: > Basically, it reduces the database to a place to throw data and get it > back a little later. Everything else is client-side processing Of course what you get back might well not be what you put in... :) > So, back on the subject, does someone see a good advocacy opportunity > here? I think many students would be able to help if we devised some > ways to advocate PostgreSQL in that kind of environment without > distracting from the main topics in the course. > > Basically, here's what I've got so far: > (1) Make passive comments about PostgreSQL when appropriate, and mention > the name "PostgreSQL". For example, if the professor asks a question > that could be answered by "the PostgreSQL way". > (2) I started work on a project a while ago to improve concurrent > seqential scans of the same table. It works, but it needs testing and > needs to be better integrated with PostgreSQL source conventions. I'll > mention it to the professor and see if he's interested in helping me. If > so, he's bound to gain some real respect for PostgreSQL. These are good ideas, but I'd be a bit careful about promoting PostgreSQL too heavily. I think it's far more important to enlighten people about why MySQL (or any other database that does the things they do) is unsound. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Sat, Jul 23, 2005 at 04:46:52PM -0400, Robert Treat wrote: > > But I think it's also folly not to promote MySQL->PostgreSQL migration. > > The only advantage MySQL has over PostgreSQL is the size of the user > > community. More users means more tools means more apps written for MySQL > > means more users, etc. Many times people start off on MySQL then find > > themselves wishing they hadn't once they get some exposure to > > PostgreSQL. Yet they stay with MySQL because of how difficult it would > > be to migrate. So they stay MySQL users, giving MySQL more momentum. > > > > I'm not saying we don't want people to convert, but if the end goal is to > increase the user base, why go after a small piece of the pie? I think that > the $ql$erver/oracle user bases are signifigantly larger than my$qls that it > offsets an ease of convincing that you might have when dealing with my$ql > users. Because that small piece of the pie is where the next generation of decision makers is comming from, as well as a lot of coders. If all people at a company are hearing about is MySQL, then odds are they might not even look at PostgreSQL. Also, realistically there's a lot of territory owned by the big 3 that PostgreSQL isn't going to be able to move into anytime soon, for different reasons. In the meantime when geeks in the back offices at companies reach for an OSS database to use in some small project, which would you rather it be, MySQL or PostgreSQL? Keep in mind that as OSS databases get a foothold in companies through the back door, whichever one is more popular at a company is going to be more likely to be adopted as the corporate standard. This is one of the ways Linux worked it's way into corporations, and it's why it's important for both the PostgreSQL community and companies that offer PostgreSQL services that these back-room projects use PostgreSQL and not MySQL. > > Fortunately, since MySQL is a fairly simple database, it wouldn't be > > too difficult to offer features that would greatly ease migration. Even > > some simple things like providing an equivalent to enum would probably > > go a long way. > > I can see why people like enum, but its just not a sound way to do things. > It's kind of like how they do timestamps, sure its handy in some scenarios, > but just dumb in others. I don't think your ever going to see these features > put into mainline postgresql. Maybe you can get enterprisedb to code up a > "uppsala" mode, but outside of that I think you'd just be better off making a > website listing specific my$ql features, why people find fault in them, and > then how to work around them in pg. Oh, sure, there's plenty of 'features' in MySQL that aren't the best way to do something, but unless it breaks ACID I see no reason not to at least allow them in PostgreSQL to ease migration. Some of these things might require back-end changes, but I suspect most of them could be done through contrib or pg-foundry. Since enum would be a new type it probably doesn't require backend changes. And yes, I know I could well be the one to provide an enum type for people to use, but if people think increased support for conversion from MySQL is a Good Thing (tm) then we should figure out what things are most painful for people converting an focus on them. Out of curiosity, how do they do timestamps differently? Other than supporting things like, Feb. 31st. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Jim C. Nasby wrote:
> These are good ideas, but I'd be a bit careful about promoting
> PostgreSQL too heavily. I think it's far more important to enlighten
> people about why MySQL (or any other database that does the things they
> do) is unsound.
If I see the opportunity I'll take it. However, as Josh pointed out,
MySQL is an unlikely candidate in a university database course. I don't
expect that to even come up.
Usually it's the business/hobbyist types that we have to educate about
the problems with MySQL. Academics are probably already aware of the
pitfalls of MySQL or products like it, and are more likely to appreciate
PostgreSQL's strong points.
Regards,
Jeff Davis
On Monday 25 July 2005 16:54, Jim C. Nasby wrote:
> On Sat, Jul 23, 2005 at 04:46:52PM -0400, Robert Treat wrote:
> > > But I think it's also folly not to promote MySQL->PostgreSQL migration.
> > > The only advantage MySQL has over PostgreSQL is the size of the user
> > > community. More users means more tools means more apps written for
> > > MySQL means more users, etc. Many times people start off on MySQL then
> > > find themselves wishing they hadn't once they get some exposure to
> > > PostgreSQL. Yet they stay with MySQL because of how difficult it would
> > > be to migrate. So they stay MySQL users, giving MySQL more momentum.
> >
> > I'm not saying we don't want people to convert, but if the end goal is to
> > increase the user base, why go after a small piece of the pie? I think
> > that the $ql$erver/oracle user bases are signifigantly larger than my$qls
> > that it offsets an ease of convincing that you might have when dealing
> > with my$ql users.
>
> Because that small piece of the pie is where the next generation of
> decision makers is comming from, as well as a lot of coders. If all
> people at a company are hearing about is MySQL, then odds are they might
> not even look at PostgreSQL.
>
> Also, realistically there's a lot of territory owned by the big 3 that
> PostgreSQL isn't going to be able to move into anytime soon, for
> different reasons. In the meantime when geeks in the back offices at
> companies reach for an OSS database to use in some small project, which
> would you rather it be, MySQL or PostgreSQL? Keep in mind that as OSS
> databases get a foothold in companies through the back door, whichever
> one is more popular at a company is going to be more likely to be
> adopted as the corporate standard. This is one of the ways Linux worked
> it's way into corporations, and it's why it's important for both the
> PostgreSQL community and companies that offer PostgreSQL services that
> these back-room projects use PostgreSQL and not MySQL.
>
All this is well and good, but none of it is relevant to making good
conversion tools. There is a difference in getting people to pick postgresql
from the start and getting them to swtich after the fact; conversion tools
focus almost exclusively on the latter.
> > > Fortunately, since MySQL is a fairly simple database, it wouldn't be
> > > too difficult to offer features that would greatly ease migration. Even
> > > some simple things like providing an equivalent to enum would probably
> > > go a long way.
> >
> > I can see why people like enum, but its just not a sound way to do
> > things. It's kind of like how they do timestamps, sure its handy in some
> > scenarios, but just dumb in others. I don't think your ever going to see
> > these features put into mainline postgresql. Maybe you can get
> > enterprisedb to code up a "uppsala" mode, but outside of that I think
> > you'd just be better off making a website listing specific my$ql
> > features, why people find fault in them, and then how to work around them
> > in pg.
>
> Oh, sure, there's plenty of 'features' in MySQL that aren't the best way
> to do something, but unless it breaks ACID I see no reason not to at
> least allow them in PostgreSQL to ease migration. Some of these things
> might require back-end changes, but I suspect most of them could be done
> through contrib or pg-foundry. Since enum would be a new type it
> probably doesn't require backend changes.
>
ACID isn't the start and end point of the relational theory; just because
something doesn't break ACID doesn't make it a good idea.
> And yes, I know I could well be the one to provide an enum type for
> people to use, but if people think increased support for conversion from
> MySQL is a Good Thing (tm) then we should figure out what things are
> most painful for people converting an focus on them.
>
enum is certainly in the top 5.
> Out of curiosity, how do they do timestamps differently? Other than
> supporting things like, Feb. 31st.
Well, the rules for determining which timestamp column in a table
automatically update are confusing, especially when you factor in different
versions and things like "maxdb mode". Also they accept 0000-00-00 00:00:00
as a valid entry, which causes a lot of heartache when porting.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Jim C. Nasby wrote:
>But the problem is that grassroots OSS movements change the market once
>they get large enough. 10, or even 5 years ago it was impossible to get
>linux into big business, for many of the reasons you mentioned. But
>that's changed, even though *BSD was technically superior. It changed
>because there was a virtual army of linux users who wanted very badly to
>be able to use linux at work. MySQL has more 'foot-soldiers' than
>PostgreSQL does, even if a lot of them are alienated.
>
>
I don't want to get into a BSD v. Linux flamewar. But I think that the
most important thing that Linux did better than BSD was
community-building. Apache did an excellent job of community-building
as well.
MySQL is currently sort of a de-facto standard. However, I think we
have a more involved community here with PostgreSQL. We may have fewer
footsoldiers, but our footsoldiers are better, more technically able,
and form a larger core community than you have with MySQL.
As evidence, MySQL used to argue that PostgreSQL's rate of development
was too fast, and that their slower rate was better because it meant
things got done right. Whatever.....
Finally, I would say that I have avoided MySQL since PostgreSQL 7.0 came
out. Like many people, I found MySQL easier to use before that point.
But with advances in usability, PostgreSQL has become an extremely easy
to use and powerful product. I am able to get so much more done faster
with PostgreSQL, and my queries run faster. For example:
SELECT ar1.invnumber AS invoice1, ar2.invnumber AS invoice2,
ar1.amount, ar1.paid, ar1.duedate
FROM ar ar1, ar ar2
WHERE ar1.invnumber::numeric > (ar2.invnumber::numeric - 3::numeric)
AND ar1.invnumber::numeric < (ar2.invnumber::numeric + 3::numeric) AND
ar1.amount = ar2.amount
AND ar1.invnumber <> ar2.invnumber AND ar1.till::text = ar2.till::text
AND ar1.duedate = ar2.duedate AND ar1.employee_id = ar2.employee_id AND
NOT (ar1.id IN ( SELECT i1.trans_id
FROM invoice i1
WHERE i1.trans_id = ar1.id AND NOT (i1.parts_id IN ( SELECT
i2.parts_id
FROM invoice i2
WHERE i2.trans_id = ar2.id AND i2.parts_id =
i1.parts_id AND i1.qty = i2.qty)))) AND NOT (ar1.id IN ( SELECT ac1.trans_id
FROM acc_trans ac1
WHERE ac1.source IS NOT NULL AND ac1.trans_id = ar1.id AND NOT
(ac1.amount IN ( SELECT ac2.amount
FROM acc_trans ac2
WHERE ar2.id = ac2.trans_id AND ac2.source =
ac1.source AND ac2.source IS NOT NULL AND ac1.amount = ac2.amount))))
AND ar1.amount <> 0::double precision
ORDER BY ar1.invnumber::numeric;
ran in a reasonable amount of time. Running the same query in MySQL
would have been much slower.
>Second (and probably more important), we need to make it easier for
>people to migrate to PostgreSQL from MySQL. There's a sizeable number of
>people who would like to migrate things off of MySQL if it wasn't so
>difficult, and hard to do incrementally. Adding support for some MySQL
>features (such as enum and tinyint), making it easy for PostgreSQL
>databases to talk to MySQL databases (perhaps via dblink), and providing
>methods to connect to PostgreSQL without having to tear out big chunks
>of un-abstracted code are some things that would help here.
>
>
How hard would it be to automatically create enum_ tables in the back
ground to emulate MySQL's enum type? Sort of like we do with SERIAL
datatypes... Part of the problem is that MySQL's enum type is so
braindead from a database design perspective that most of us would not
be interested in using it. Emulating an int foreign key for another
created table might make it ok, though.
Also, why not simply allow tinyint to be the same as int(2)?
Personally, I agree that we should pursue MySQL compatibility along with
compatibility for the large "real" RDBMS. Simply because it means a
larger, more diverse community.
Best Wishes,
Chris Travers
Metatron Technology Consulting
On Tue, Jul 26, 2005 at 12:26:57PM -0700, Chris Travers wrote: > Jim C. Nasby wrote: > > >But the problem is that grassroots OSS movements change the market once > >they get large enough. 10, or even 5 years ago it was impossible to get > >linux into big business, for many of the reasons you mentioned. But > >that's changed, even though *BSD was technically superior. It changed > >because there was a virtual army of linux users who wanted very badly to > >be able to use linux at work. MySQL has more 'foot-soldiers' than > >PostgreSQL does, even if a lot of them are alienated. > > > > > I don't want to get into a BSD v. Linux flamewar. But I think that the > most important thing that Linux did better than BSD was > community-building. Apache did an excellent job of community-building > as well. Agreed. And this is why I think it's important to make it easy to bring current MySQL users into the fold. > MySQL is currently sort of a de-facto standard. However, I think we > have a more involved community here with PostgreSQL. We may have fewer > footsoldiers, but our footsoldiers are better, more technically able, > and form a larger core community than you have with MySQL. > > As evidence, MySQL used to argue that PostgreSQL's rate of development > was too fast, and that their slower rate was better because it meant > things got done right. Whatever..... They also used to argue that table locking was better than row locking... So, how can we increase awareness amongst people who have yet to choose an OSS database? Awareness that PostgreSQL exists, and awareness that it's almost always a superior choice than MySQL. > >Second (and probably more important), we need to make it easier for > >people to migrate to PostgreSQL from MySQL. There's a sizeable number of > >people who would like to migrate things off of MySQL if it wasn't so > >difficult, and hard to do incrementally. Adding support for some MySQL > >features (such as enum and tinyint), making it easy for PostgreSQL > >databases to talk to MySQL databases (perhaps via dblink), and providing > >methods to connect to PostgreSQL without having to tear out big chunks > >of un-abstracted code are some things that would help here. > > > > > How hard would it be to automatically create enum_ tables in the back > ground to emulate MySQL's enum type? Sort of like we do with SERIAL > datatypes... Part of the problem is that MySQL's enum type is so > braindead from a database design perspective that most of us would not > be interested in using it. Emulating an int foreign key for another > created table might make it ok, though. This is something that's been discussed on IRC, and got a favorable response. In terms of compatability, I'd be happy with something that just emulated MySQL. I think it would actually be good to allow for both, since there are some limited cases where it doesn't make sense to use an integer pointer to an external table. > Also, why not simply allow tinyint to be the same as int(2)? Again, for simple compatability that would be fine. If alignment/padding issues could be dealt with, it would also be handy to have a true tinyint. > Personally, I agree that we should pursue MySQL compatibility along with > compatibility for the large "real" RDBMS. Simply because it means a > larger, more diverse community. Would you be interested in supporting a pg-foundry project that worked on increasing mysql compatabality? -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Chris Travers wrote:
>>
> How hard would it be to automatically create enum_ tables in the back
> ground to emulate MySQL's enum type? Sort of like we do with SERIAL
> datatypes... Part of the problem is that MySQL's enum type is so
> braindead from a database design perspective that most of us would not
> be interested in using it. Emulating an int foreign key for another
> created table might make it ok, though.
>
The thing that occurs to me is that if you really want the enum type in
PostgreSQL (assuming that there exists a real need), a PostgreSQL person
would create their own type. Or, if not, just create a wrapper function
that handles the input/output display and call it explicitly.
So to me, the need seems very weak. However, if your goal is
compatibility, I guess we need it. The problem is it's very difficult to
do in a general way. We'd probably have to do it specifically for enum,
and have it generate the types automatically on the fly. Someone would
have to do some interesting things with the parser, too. Right now even
the varchar() type, for instance, is kind of a hack.
Ultimately to do it in a general way I think we'd need functions that
return a type that can be used in a table definition. Aside from the
many problems I don't know about, there are two other problems:
(1) After the table (or column?) is dropped, we need to drop the type.
(2) Functions currently don't support variable numbers of arguments, so
enum still wouldn't be simple. We could do something kinda dumb-looking
like:
CREATE TABLE mytable (
color ENUM("red,green,blue,orange,purple,yellow");
);
And have the hypothetical ENUM function then parse the single argument
and return a type that could be used by that table.
Is this achievable with a reasonable amount of effort? Is this
function-returning-a-type a reasonable behavior?
If nothing else it would clean up the clutter of varchar() and the like,
that currently use the hacked-in catalog entry "atttypmod" or something
like that.
Regards,
Jeff Davis
Jim C. Nasby wrote: > So, how can we increase awareness amongst people who have yet to choose > >an OSS database? Awareness that PostgreSQL exists, and awareness that >it's almost always a superior choice than MySQL. > > > We help migrate apps to PostgreSQL. We help other people run PostgreSQL. We show them the features that they really cannot live without, such as schemas, views, etc. We also show them the power of extensible types and extensible UDF languages. >This is something that's been discussed on IRC, and got a favorable >response. In terms of compatability, I'd be happy with something that >just emulated MySQL. I think it would actually be good to allow for >both, since there are some limited cases where it doesn't make sense to >use an integer pointer to an external table. > > I would rather do things so that it covered 90% of all cases and did so *right* than something that covered 100% of cases and did so by breaking basic principles of database design. The enum_ table idea would work well for all major uses that I can think of, and it would easily allow new options to be added as necessary. The problem with enums is that although they are handy they are never elegant re: database design. Addign enum tables is the only way yo maintain sanity in this eent that I can think of. > > >>Also, why not simply allow tinyint to be the same as int(2)? >> >> > >Again, for simple compatability that would be fine. If alignment/padding >issues could be dealt with, it would also be handy to have a true >tinyint. > > > Ok. Bruce pointed out that there is a datatype "char" (with the quotes) that is basically a single byte of info. We could maybe have tinyint use that? Or for that, how hard would it be to write a simple datatype (Occam's Razor-- One Should Not Needlessly Multiply Entities-- would lead us to think that this is a bad idea when existing datatypes meet this need)? That should be rediculously easy for a single byte of information presented as an int. >Would you be interested in supporting a pg-foundry project that worked >on increasing mysql compatabality? > > I would be interested in one that worked on decreasing migration costs. I am thinking less in terms of compatibility, but more in terms of helping shim an existing MySQL-based app so that it works on PostgreSQL, and helping shim PostgreSQL so that it can accept input as expected from MySQL. 100% compatibility would mean though that we would have to do things I would never advocate, such as emulating MySQL's braindead error handling. Best Wishes, Chris Travers
On Tue, Jul 26, 2005 at 01:09:11PM -0700, Jeff Davis wrote:
> Chris Travers wrote:
> >>
> > How hard would it be to automatically create enum_ tables in the back
> > ground to emulate MySQL's enum type? Sort of like we do with SERIAL
> > datatypes... Part of the problem is that MySQL's enum type is so
> > braindead from a database design perspective that most of us would not
> > be interested in using it. Emulating an int foreign key for another
> > created table might make it ok, though.
> >
>
> The thing that occurs to me is that if you really want the enum type in
> PostgreSQL (assuming that there exists a real need), a PostgreSQL person
> would create their own type. Or, if not, just create a wrapper function
> that handles the input/output display and call it explicitly.
OK, but compare the amount of work you just described to the simplicity
of using an enum. Enum is much easier and simpler for a developer. Of
course in most cases the MySQL way of doing it is (as has been
mentioned) stupid, but done in the normal, normalized way it would
remove a fair amount of additional work on the part of a developer:
- no need to manually define seperate table
- no need to define RI
- no need to manually map between ID and real values (though of course
we should make it easy to get the ID too)
> So to me, the need seems very weak. However, if your goal is
> compatibility, I guess we need it. The problem is it's very difficult to
> do in a general way. We'd probably have to do it specifically for enum,
> and have it generate the types automatically on the fly. Someone would
> have to do some interesting things with the parser, too. Right now even
> the varchar() type, for instance, is kind of a hack.
>
> Ultimately to do it in a general way I think we'd need functions that
> return a type that can be used in a table definition. Aside from the
> many problems I don't know about, there are two other problems:
> (1) After the table (or column?) is dropped, we need to drop the type.
> (2) Functions currently don't support variable numbers of arguments, so
> enum still wouldn't be simple. We could do something kinda dumb-looking
> like:
> CREATE TABLE mytable (
> color ENUM("red,green,blue,orange,purple,yellow");
> );
> And have the hypothetical ENUM function then parse the single argument
> and return a type that could be used by that table.
>
> Is this achievable with a reasonable amount of effort? Is this
> function-returning-a-type a reasonable behavior?
>
> If nothing else it would clean up the clutter of varchar() and the like,
> that currently use the hacked-in catalog entry "atttypmod" or something
> like that.
Hopefully someone on -hackers can shed light on what's required to clean
up the parsing. One thing worth noting though, is that table definition
is a relatively small part of doing a migration. Generally, it's
application code that causes the most issues. Because of this, I think
there would still be a lot of benefit to an enum type that didn't
strictly follow the mysql naming/definition convention. In this case, it
might be much easier to have an enum that doesn't allow you to define
what can go into it at creation time; ie:
CREATE TABLE ...
blah ENUM NOT NULL ...
...
ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4);
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 26, 2005 at 01:20:58PM -0700, Chris Travers wrote: > We help migrate apps to PostgreSQL. We help other people run > PostgreSQL. We show them the features that they really cannot live > without, such as schemas, views, etc. > > We also show them the power of extensible types and extensible UDF > languages. And what do we use as a platform for this? <dons flame suit> Should we have a "Why you probably don't want to use MySQL" document somewhere on the site? > >This is something that's been discussed on IRC, and got a favorable > >response. In terms of compatability, I'd be happy with something that > >just emulated MySQL. I think it would actually be good to allow for > >both, since there are some limited cases where it doesn't make sense to > >use an integer pointer to an external table. > > > > > I would rather do things so that it covered 90% of all cases and did so > *right* than something that covered 100% of cases and did so by breaking > basic principles of database design. The enum_ table idea would work > well for all major uses that I can think of, and it would easily allow > new options to be added as necessary. The case I'm thinking of is when you have a small table that you want to have an enum-like field in; in such a case using an ID to reference another table every time you want to find a value probably doesn't make sense. But if you've got a moderately large number of allowable values (say more than a couple dozen), maintaining a check constraint to handle the ENUM might be a bear. But as you mentioned, if we're careful with syntax the type can always be expanded. Another interesting use case would be an enum that automatically adds new values to the lookup table if they don't already exist. I know it's no longer an enum in the traditional sense, but this is a common enough use case that it would be very convenient to have. > >Again, for simple compatability that would be fine. If alignment/padding > >issues could be dealt with, it would also be handy to have a true > >tinyint. > > > Ok. Bruce pointed out that there is a datatype "char" (with the quotes) > that is basically a single byte of info. We could maybe have tinyint > use that? Or for that, how hard would it be to write a simple datatype > (Occam's Razor-- One Should Not Needlessly Multiply Entities-- would > lead us to think that this is a bad idea when existing datatypes meet > this need)? That should be rediculously easy for a single byte of > information presented as an int. Excellent idea, I'd forgotten about that type. I suspect it would be perfectly useful as both a tinyint and a tinyuint (if we wanted to add that as well; I honestly don't know if MySQL has one or not). > >Would you be interested in supporting a pg-foundry project that worked > >on increasing mysql compatabality? > > > I would be interested in one that worked on decreasing migration costs. > I am thinking less in terms of compatibility, but more in terms of > helping shim an existing MySQL-based app so that it works on PostgreSQL, > and helping shim PostgreSQL so that it can accept input as expected from > MySQL. > > 100% compatibility would mean though that we would have to do things I > would never advocate, such as emulating MySQL's braindead error handling. Agreed and agreed. I'm absolutely opposed to continuing dumb mistakes made by MySQL. This should be an example of how they should have done things in the first place. I'm starting a new job next week that might allow doing this kind of work with some official corporate sponsorship. Because of that I'm going to hold off a bit on creating a pg-foundry project (though I suspect that's where this will be hosted anyway). In any case, expect to see something mid-next week. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Jim C. Nasby wrote:
>OK, but compare the amount of work you just described to the simplicity
>of using an enum. Enum is much easier and simpler for a developer. Of
>course in most cases the MySQL way of doing it is (as has been
>mentioned) stupid, but done in the normal, normalized way it would
>remove a fair amount of additional work on the part of a developer:
>
>- no need to manually define seperate table
>- no need to define RI
>- no need to manually map between ID and real values (though of course
> we should make it easy to get the ID too)
>
>
>
Again, automating this process is the only way I can see this done in a
normalized way. I think that having type definitions (enum options) in
the table definition is in general a very bad idea. A simple option
would be to have it be a VARCHAR referencing a single column VARCHAR
table with a primary key on the VARCHAR column. Not as
storage-efficient as an int, but better at compatibility.
>
>Hopefully someone on -hackers can shed light on what's required to clean
>up the parsing. One thing worth noting though, is that table definition
>is a relatively small part of doing a migration. Generally, it's
>application code that causes the most issues. Because of this, I think
>there would still be a lot of benefit to an enum type that didn't
>strictly follow the mysql naming/definition convention. In this case, it
>might be much easier to have an enum that doesn't allow you to define
>what can go into it at creation time; ie:
>
>CREATE TABLE ...
> blah ENUM NOT NULL ...
>...
>
>ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4);
>
>
What about the possibility of using a domain... One could alter the
code using conversion tools....
Something like:
CREATE TABLE table_name (
val_name ENUM(option1, option2, option3) NOT NULL,
);
would be rewritten to:
CREATE DOMAIN table_name_val_name_enum AS VARCHAR DEFAULT NULL CHECK IN
('option1', 'option2', 'option3');
CREATE TABLE table_name (
val_name table_name_val_name_enum NOT NULL,
);
This could be added to the mysql2pg scripts.
Best Wishes,
Chris Travers
Metatron Technology Consulting
Jim C. Nasby wrote:
> So, how can we increase awareness amongst people who have yet to choose
> an OSS database? Awareness that PostgreSQL exists, and awareness that
> it's almost always a superior choice than MySQL.
>
There's actually pretty good awareness that PostgreSQL exists. However,
we aren't going to win the battle before people try PostgreSQL. The main
battles are getting important tools to use PostgreSQL, and getting
people to just try it out.
I think most people are very quickly impressed by PostgreSQL because it
is so consistant and you can almost feel the data integrity. Every
feature of PostgreSQL is part of a grand-unified, general solution. Good
examples would be extensible procedural languages, user-defined
functions, user defined types, GiST, etc. And to see how useful all of
those things are, you need to look no further than the likes of tsearch2.
The hardest part of getting a user to stay with PostgreSQL is taking
them from "OSS databases are MySQL and PostgreSQL in that order" to
getting their first helpful reply from the lists. I think that's the
place we really win them over, because they come in looking for a
checklist feature or a problem. Often they don't understand the
"feature" or they expect to stump the lists with their problem. Then
someone steps up and explains to them the right way to do it, why it's
the right way, and why PostgreSQL is the best database. And the reason
that wins them over is because usually they walk away thinking "wow,
that makes a lot more sense".
One thing that used to come up all the time on the lists was "PostgreSQL
won't use my index, how can I force it to?". Sometimes this resulted in
some fine tuning of the postgresql.conf, or even enable_seqscan=false.
However, many times it resulted in explaining that the planner concluded
that seqscan was faster, followed by an explanation of why the planner
thought so, followed by a demonstration that the seqscan was faster.
Imagine if you're a MySQL user, and you get an answer to a question like
that. You'd stick with PostgreSQL from that point on. That happened to
me 5 years ago (probably with a different question, it was a while ago,
but the point is the lists quickly set me straight :), and it certainly
worked, even though that was before 7.0 came out, and MySQL was more usable.
Regards,
Jeff Davis
Jim C. Nasby wrote: > >And what do we use as a platform for this? > ><dons flame suit> Should we have a "Why you probably don't want to use >MySQL" document somewhere on the site? > > > It would be better to have a "Benefits over MySQL" page. Something like: * More robust error handling * Better optimization * Triggers * Add your own language for stored procedures * Add your own data types * Better standards compliance * Lower cost of development * Fewer licensing issues In fact, having a maintained feature sheet listing PostgreSQL, MySQL, and FirebirdSQL probably wouldn't be a bad idea. >The case I'm thinking of is when you have a small table that you want to >have an enum-like field in; in such a case using an ID to reference >another table every time you want to find a value probably doesn't make >sense. But if you've got a moderately large number of allowable values >(say more than a couple dozen), maintaining a check constraint to handle >the ENUM might be a bear. > > Probably the best way of doing this is to have a VARCHAR primary key in the enum table (sole column), and a VARCHAR foreign key referencing it. >But as you mentioned, if we're careful with syntax the type can always >be expanded. Another interesting use case would be an enum that >automatically adds new values to the lookup table if they don't already >exist. I know it's no longer an enum in the traditional sense, but this >is a common enough use case that it would be very convenient to have. > > This could be done with triggers and deferred RI constraints. However, how does it differ from a VARCHAR? > Agreed and agreed. I'm absolutely opposed to continuing dumb mistakes > >made by MySQL. This should be an example of how they should have done >things in the first place. > >I'm starting a new job next week that might allow doing this kind of >work with some official corporate sponsorship. Because of that I'm going >to hold off a bit on creating a pg-foundry project (though I suspect >that's where this will be hosted anyway). In any case, expect to see >something mid-next week. > > I will be bringing this up to another possibly interested party as well. Best Wishes, Chris Travers
Chris Travers wrote:
> The problem with enums is that although they are handy they are never
> elegant re: database design. Addign enum tables is the only way yo
> maintain sanity in this eent that I can think of.
>
I mostly agree, but I don't think we can dismiss enum completely. After
all, boolean is pretty much enum(false,true), and nobody would advocate
removing that type.
We could probably think of a few other cases, but it's often used
inappropriately. Just the fact that we're talking about it now surprises
me; I had no idea that many people actually used enum. The thought of
using it never crossed my mind in a real situation.
Regards,
Jeff Davis
Jim C. Nasby wrote:
>
> OK, but compare the amount of work you just described to the simplicity
> of using an enum. Enum is much easier and simpler for a developer. Of
> course in most cases the MySQL way of doing it is (as has been
> mentioned) stupid, but done in the normal, normalized way it would
> remove a fair amount of additional work on the part of a developer:
>
> - no need to manually define seperate table
> - no need to define RI
> - no need to manually map between ID and real values (though of course
> we should make it easy to get the ID too)
>
>
Yeah, you're right. But this is only in the case where someone cares
about using an int rather than a string type for some performance
reason. If they don't mind wasting a few bytes (and it's really only a
few bytes per record), then why not just use a check constraint when
defining the table (like Chris explains)?
> Hopefully someone on -hackers can shed light on what's required to clean
> up the parsing. One thing worth noting though, is that table definition
> is a relatively small part of doing a migration. Generally, it's
> application code that causes the most issues. Because of this, I think
> there would still be a lot of benefit to an enum type that didn't
> strictly follow the mysql naming/definition convention. In this case, it
> might be much easier to have an enum that doesn't allow you to define
> what can go into it at creation time; ie:
>
> CREATE TABLE ...
> blah ENUM NOT NULL ...
> ...
>
> ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4);
Interesting. I'm not really sure exactly what syntax we want to use, but
as long as it gets the job done and is reasonable to implement.
Regards,
Jeff Davis
Chris, > How hard would it be to automatically create enum_ tables in the back > ground to emulate MySQL's enum type? Sort of like we do with SERIAL > datatypes... Part of the problem is that MySQL's enum type is so > braindead from a database design perspective that most of us would not > be interested in using it. Emulating an int foreign key for another > created table might make it ok, though. The mysql2postgres.pl script actually does this (create enum types). It would be better to auto-create a table and FK, though. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Tue, Jul 26, 2005 at 01:53:54PM -0700, Chris Travers wrote: > Jim C. Nasby wrote: > > > > >And what do we use as a platform for this? > > > ><dons flame suit> Should we have a "Why you probably don't want to use > >MySQL" document somewhere on the site? > > > > > > > It would be better to have a "Benefits over MySQL" page. Something like: Well, I guess that's a more polite way to put it, but it misses the real point: MySQL does a lot of things that are at best not a very good way to do them and at worst put your data at serious risk. Many people simply have no idea about these issues. So while it'd be nice if these people chose PostgreSQL over MySQL, I personally think it's more important that they save themselves (and others) the pain that's likely to follow from deciding to use MySQL. BTW, your list is missing some critical items, such as silent data truncation, count(*) returning an estimate, how there's numerous ways to configure MySQL so it's not ACID without even knowing it, etc. In other words, problems that make it easy to trash your data (without even knowing it), as opposed to standard database features that are just missing. > In fact, having a maintained feature sheet listing PostgreSQL, MySQL, > and FirebirdSQL probably wouldn't be a bad idea. That's probably not a bad idea either, just to give people an idea of how the different projects stack up. SQLlite would probably be a good addition to that list as well. > >The case I'm thinking of is when you have a small table that you want to > >have an enum-like field in; in such a case using an ID to reference > >another table every time you want to find a value probably doesn't make > >sense. But if you've got a moderately large number of allowable values > >(say more than a couple dozen), maintaining a check constraint to handle > >the ENUM might be a bear. > > > > > Probably the best way of doing this is to have a VARCHAR primary key in > the enum table (sole column), and a VARCHAR foreign key referencing it. Yup. Or text for that matter... > >But as you mentioned, if we're careful with syntax the type can always > >be expanded. Another interesting use case would be an enum that > >automatically adds new values to the lookup table if they don't already > >exist. I know it's no longer an enum in the traditional sense, but this > >is a common enough use case that it would be very convenient to have. > > > > > This could be done with triggers and deferred RI constraints. However, > how does it differ from a VARCHAR? I know it can be done now; I'm just saying it would make the developers job a bit easier. As for varchar, they're orthogonal issues. If you have a large table with a limited number of text values that could change over time you'd want to store an integer ID in the large table, but make it easy to deal with new values being added. > >Agreed and agreed. I'm absolutely opposed to continuing dumb mistakes > > > >made by MySQL. This should be an example of how they should have done > >things in the first place. > > > >I'm starting a new job next week that might allow doing this kind of > >work with some official corporate sponsorship. Because of that I'm going > >to hold off a bit on creating a pg-foundry project (though I suspect > >that's where this will be hosted anyway). In any case, expect to see > >something mid-next week. > > > > > I will be bringing this up to another possibly interested party as well. > > Best Wishes, > Chris Travers > -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 26, 2005 at 01:48:36PM -0700, Jeff Davis wrote: > Jim C. Nasby wrote: > > > So, how can we increase awareness amongst people who have yet to choose > > an OSS database? Awareness that PostgreSQL exists, and awareness that > > it's almost always a superior choice than MySQL. > > > > There's actually pretty good awareness that PostgreSQL exists. However, > we aren't going to win the battle before people try PostgreSQL. The main > battles are getting important tools to use PostgreSQL, and getting > people to just try it out. <snip> > The hardest part of getting a user to stay with PostgreSQL is taking > them from "OSS databases are MySQL and PostgreSQL in that order" to > getting their first helpful reply from the lists. I think that's the > place we really win them over, because they come in looking for a > checklist feature or a problem. Often they don't understand the > "feature" or they expect to stump the lists with their problem. Then > someone steps up and explains to them the right way to do it, why it's > the right way, and why PostgreSQL is the best database. And the reason > that wins them over is because usually they walk away thinking "wow, > that makes a lot more sense". So, suggestions for how to get them to that stage? :) -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 26, 2005 at 01:42:42PM -0700, Chris Travers wrote:
> Jim C. Nasby wrote:
>
> >OK, but compare the amount of work you just described to the simplicity
> >of using an enum. Enum is much easier and simpler for a developer. Of
> >course in most cases the MySQL way of doing it is (as has been
> >mentioned) stupid, but done in the normal, normalized way it would
> >remove a fair amount of additional work on the part of a developer:
> >
> >- no need to manually define seperate table
> >- no need to define RI
> >- no need to manually map between ID and real values (though of course
> > we should make it easy to get the ID too)
> >
> Again, automating this process is the only way I can see this done in a
> normalized way.
Not quite shure what you mean there...
> I think that having type definitions (enum options) in
> the table definition is in general a very bad idea. A simple option
Why?
> What about the possibility of using a domain... One could alter the
> code using conversion tools....
>
> Something like:
> CREATE TABLE table_name (
> val_name ENUM(option1, option2, option3) NOT NULL,
> );
>
>
> would be rewritten to:
> CREATE DOMAIN table_name_val_name_enum AS VARCHAR DEFAULT NULL CHECK IN
> ('option1', 'option2', 'option3');
> CREATE TABLE table_name (
> val_name table_name_val_name_enum NOT NULL,
> );
>
> This could be added to the mysql2pg scripts.
That's a good idea for a stop-gap, or if no one wants to put the effort
into creating a useful enum type.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
Jim, Merlin, > > This could be added to the mysql2pg scripts. Per my other e-mail, it's already in mysql2pgsql.pl > That's a good idea for a stop-gap, or if no one wants to put the effort > into creating a useful enum type. I'm personally not convinced that ENUM *is* useful. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Tue, Jul 26, 2005 at 02:05:17PM -0700, Jeff Davis wrote: > Jim C. Nasby wrote: > > > > > OK, but compare the amount of work you just described to the simplicity > > of using an enum. Enum is much easier and simpler for a developer. Of > > course in most cases the MySQL way of doing it is (as has been > > mentioned) stupid, but done in the normal, normalized way it would > > remove a fair amount of additional work on the part of a developer: > > > > - no need to manually define seperate table > > - no need to define RI > > - no need to manually map between ID and real values (though of course > > we should make it easy to get the ID too) > > > > > > Yeah, you're right. But this is only in the case where someone cares > about using an int rather than a string type for some performance > reason. If they don't mind wasting a few bytes (and it's really only a > few bytes per record), then why not just use a check constraint when > defining the table (like Chris explains)? Normalization is about a lot more than just saving space in your base tables. But since that's the example you used, you a) can't assume it's only a few bytes and b) can't assume that those few bytes won't start to seriously add up over the span of a few hundred million rows. Remember: while disk space might be cheap, disk I/O bandwidth costs a fortune. > > Hopefully someone on -hackers can shed light on what's required to clean > > up the parsing. One thing worth noting though, is that table definition > > is a relatively small part of doing a migration. Generally, it's > > application code that causes the most issues. Because of this, I think > > there would still be a lot of benefit to an enum type that didn't > > strictly follow the mysql naming/definition convention. In this case, it > > might be much easier to have an enum that doesn't allow you to define > > what can go into it at creation time; ie: > > > > CREATE TABLE ... > > blah ENUM NOT NULL ... > > ... > > > > ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4); > > Interesting. I'm not really sure exactly what syntax we want to use, but > as long as it gets the job done and is reasonable to implement. Yeah, like I said the real key is just making sure it works the same from an application's viewpoint (which generally doesn't involve any DDL). -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Tue, Jul 26, 2005 at 03:30:11PM -0700, Josh Berkus wrote: > > That's a good idea for a stop-gap, or if no one wants to put the effort > > into creating a useful enum type. > > I'm personally not convinced that ENUM *is* useful. ENUM as MySQL does it, or as something that consolodates the many steps involved in setting up a simple normalized view for a field that provides automatic mapping so that the application thinks it's just dealing with a text/varchar? ISTM that given how common the use case is and the non-trivial amount of code involved that it's worth attempting. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Jim, > ENUM as MySQL does it Well, that's the only version I'm familiar with. You've not posted a spec for *your* version yet. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Jim C. Nasby wrote: >On Tue, Jul 26, 2005 at 01:53:54PM -0700, Chris Travers wrote: > > >>Jim C. Nasby wrote: >> >> >> >>>And what do we use as a platform for this? >>> >>><dons flame suit> Should we have a "Why you probably don't want to use >>>MySQL" document somewhere on the site? >>> >>> >>> >>> >>> >>It would be better to have a "Benefits over MySQL" page. Something like: >> >> > >Well, I guess that's a more polite way to put it, but it misses the real >point: MySQL does a lot of things that are at best not a very good way >to do them and at worst put your data at serious risk. Many people >simply have no idea about these issues. So while it'd be nice if these >people chose PostgreSQL over MySQL, I personally think it's more >important that they save themselves (and others) the pain that's likely >to follow from deciding to use MySQL. > > While you are correct in pointing this out, there is an issue here. Do we really want to position ourselves as talking bad about our competition publically? I say we don't simply because it is a very good way to drive away potential users. Also there is something to be said about not comparing yourself too much to your competition in the commercial world though much of this doesn't really apply here in the FOSS world. What I would like to see, however, are two things: 1) A maintained features card comparing FOSS databases. We could add a feature to the list called "Strict data integrity enforcement." 2) A maintained features card comparing PostgreSQL and commercial databases.RDBMS's. >BTW, your list is missing some critical items, such as silent data >truncation, count(*) returning an estimate, how there's numerous ways to >configure MySQL so it's not ACID without even knowing it, etc. In other >words, problems that make it easy to trash your data (without even >knowing it), as opposed to standard database features that are just >missing. > > I agree to an extent. I just don't want to see the community position ourselves as being unprofessionally opposed to our main FOSS competition. I think that this will drive users *away* rather than *to* PostgreSQL. > > >>In fact, having a maintained feature sheet listing PostgreSQL, MySQL, >>and FirebirdSQL probably wouldn't be a bad idea. >> >> > >That's probably not a bad idea either, just to give people an idea of >how the different projects stack up. SQLlite would probably be a good >addition to that list as well. > > And Ingress II, as well, as I think about it. > >>>But as you mentioned, if we're careful with syntax the type can always >>>be expanded. Another interesting use case would be an enum that >>>automatically adds new values to the lookup table if they don't already >>>exist. I know it's no longer an enum in the traditional sense, but this >>>is a common enough use case that it would be very convenient to have. >>> >>> >>> >>> >>This could be done with triggers and deferred RI constraints. However, >>how does it differ from a VARCHAR? >> >> > >I know it can be done now; I'm just saying it would make the developers >job a bit easier. > > > >As for varchar, they're orthogonal issues. If you have a large table >with a limited number of text values that could change over time you'd >want to store an integer ID in the large table, but make it easy to deal >with new values being added. > > So basically here you are looking for a type which will automatically keep track of a limited number of used values. I will say I don't like this option because it feels like premature optimization, and would rather take my time with an index scan. And where it is useful, I think it is often added after the fact. Best Wishes, Chris Travers Metatron Technology Consulting
Jim C. Nasby wrote:
>>The hardest part of getting a user to stay with PostgreSQL is taking
>>them from "OSS databases are MySQL and PostgreSQL in that order" to
>>getting their first helpful reply from the lists. I think that's the
>>place we really win them over, because they come in looking for a
>>checklist feature or a problem. Often they don't understand the
>>"feature" or they expect to stump the lists with their problem. Then
>>someone steps up and explains to them the right way to do it, why it's
>>the right way, and why PostgreSQL is the best database. And the reason
>>that wins them over is because usually they walk away thinking "wow,
>>that makes a lot more sense".
>
>
> So, suggestions for how to get them to that stage? :)
I think we are for the most part. It's a little slow. The best way to
improve that is by having more tools. Most tools are either for MySQL,
or they are "DB-independent", which basically means they don't use any
features in PostgreSQL that aren't in MySQL. The applications of
PostgreSQL specificly are often custom, and not widely deployed.
From what I understand, win32 helped a lot. There seems to be some new
names on the general list, and that's always a good sign.
Also, I think what's more important to MySQL than pretty much anything
else is that slashdot uses MySQL and everyone knows it. If somehow
slashdot magically switched to PostgreSQL and saved money and improved
availability, PostgreSQL would instantly be on top. The problem is, for
preexisting apps there is not nearly the incentive. A lot of the benefit
of PostgreSQL is faster development of an application and fewer bugs.
It's too bad sourceforge dumped PostgreSQL...
Regards,
Jeff Davis
Jim C. Nasby wrote:
>>
>>Yeah, you're right. But this is only in the case where someone cares
>>about using an int rather than a string type for some performance
>>reason. If they don't mind wasting a few bytes (and it's really only a
>>few bytes per record), then why not just use a check constraint when
>>defining the table (like Chris explains)?
>
>
> Normalization is about a lot more than just saving space in your base
> tables. But since that's the example you used, you a) can't assume it's
> only a few bytes and b) can't assume that those few bytes won't start to
> seriously add up over the span of a few hundred million rows.
>
> Remember: while disk space might be cheap, disk I/O bandwidth costs a
> fortune.
>
First, I doubt there exists a single case in the universe where someone
has 100 million rows of an enum type in MySQL, and they want to convert
to PostgreSQL without redefining their tables.
I would say the separate table is the way I would do it, but as far as a
conversion from MySQL->PostgreSQL, why are we trying to normalize their
tables along the way? Wouldn't the simple solution be the way to get
them started?
Nobody is going to expect that much from a conversion. They get their
app going on PostgreSQL, and slowly start to do things the right way. If
we hide the fact that we're normalizing their data, how does that really
help them?
However, it's fine with me if we do it that way. If there's additional
effort I just don't know whether it's worth it.
Regards,
Jeff Davis
Jeff Davis wrote: > >>Normalization is about a lot more than just saving space in your base >>tables. But since that's the example you used, you a) can't assume it's >>only a few bytes and b) can't assume that those few bytes won't start to >>seriously add up over the span of a few hundred million rows. >> >>Remember: while disk space might be cheap, disk I/O bandwidth costs a >>fortune. >> >> >> > > > First, just to be straight-- I see normalization as having two benefits neither have anything to do with disk access. The first is that the database is easier to maintain when it is atomically defined. The second is that it helps ensure that data is always maintained in a meaningful fashion. Disk I/O is a different issue and in my mind not really connected to normalization. The varchar primary key idea (which I think is probably the best solution) is certainly normalized, but it is also certainly inefficient disk-wise. >First, I doubt there exists a single case in the universe where someone >has 100 million rows of an enum type in MySQL, and they want to convert >to PostgreSQL without redefining their tables. > >I would say the separate table is the way I would do it, but as far as a >conversion from MySQL->PostgreSQL, why are we trying to normalize their >tables along the way? Wouldn't the simple solution be the way to get >them started? > > The bigger question is do we really want to have braindead datatypes in the backend? Also "simple" may be in the eye of the beholder here. Just because something is opaque does not necessarily make it simple. >Nobody is going to expect that much from a conversion. They get their >app going on PostgreSQL, and slowly start to do things the right way. If >we hide the fact that we're normalizing their data, how does that really >help them? > > It is not just a matter of helping them. It is also a matter of trying to provide something that some people find useful in a way that is actually reasonable from a database perspective. >However, it's fine with me if we do it that way. If there's additional >effort I just don't know whether it's worth it. > > > I actually think it would be less work to do it this way. Most of the work would already be done. I.e. we are talking largely about automating existing pieces rather than building something new. I personally don't think that this would be too hard. I might even be willing to try at some point in the near future. Best Wishes, Chris Travers Metatron Technology Consulting
Jeff Davis wrote: >I think we are for the most part. It's a little slow. The best way to >improve that is by having more tools. Most tools are either for MySQL, >or they are "DB-independent", which basically means they don't use any >features in PostgreSQL that aren't in MySQL. The applications of >PostgreSQL specificly are often custom, and not widely deployed. > > > I think one of the important strengths that PostgreSQL brings to the table is the ability to separate the application from the database. In MySQL these are very closely merged. But with schemas, views, rules, and triggers, it becomes possible for the *application* to use only a restricted subset of standard features while behind the scenes the magic works... MySQL really is a single application database where your app is very closely tied to the data definition. For example, I have a customer who uses PostgreSQL and SQL-Ledger. We have designed a large number of custom views for reporting purposes. If we wanted to, we could use triggers, views, and/or schemas to integrate it with other open source apps even though neither would have to know of the other. Best Wishes, Chris Travers Metatron Technology Consulting
On Tue, Jul 26, 2005 at 17:14:57 -0500, "Jim C. Nasby" <decibel@decibel.org> wrote: > > As for varchar, they're orthogonal issues. If you have a large table > with a limited number of text values that could change over time you'd > want to store an integer ID in the large table, but make it easy to deal > with new values being added. Maybe. Using the integer ID saves space, but requires a join on lookups that compare to the keywords. So there is a time space trade off doing this. Either way maintenance is similar. Domains are another option, but updating the keyword list requires DDL and you don't have the cascade options available directly for renaming or removing previously valid keywords. Though for short lists of keywords that change infrequently, domains may be the best performing option.
On Tue, Jul 26, 2005 at 20:59:11 -0700, Jeff Davis <jdavis-pgsql@empires.org> wrote: > > Also, I think what's more important to MySQL than pretty much anything > else is that slashdot uses MySQL and everyone knows it. If somehow I thought that was good promotion for databases other than MySQL. Slashcode is not known as being a great piece of code. I see errors returned occasionally (probably less than 1 / 1000 page loads) and I see complaints that it does not generate standard html, but I haven't personally looked at what a standards checker says about its output.
Hi, Chris Travers wrote: >> Well, I guess that's a more polite way to put it, but it misses the real >> point: MySQL does a lot of things that are at best not a very good way >> to do them and at worst put your data at serious risk. Many people >> simply have no idea about these issues. So while it'd be nice if these >> people chose PostgreSQL over MySQL, I personally think it's more >> important that they save themselves (and others) the pain that's likely >> to follow from deciding to use MySQL. >> >> > While you are correct in pointing this out, there is an issue here. Do > we really want to position ourselves as talking bad about our > competition publically? I say we don't simply because it is a very good > way to drive away potential users. Well, in case you didn't know MySQL had an unfair comparison to PostgreSQL right in their manual. It didn't really drive away users, in fact it created the whole generation of users who never saw PostgreSQL but repeated the BS from this "comparison". In fact they *still* have this comparison in manual's Russian translation: http://dev.mysql.com/doc/mysql/ru/compare-postgresql.html I doubt anyone except me reads Russian here, but everyone may recognize the "PostgreSQL" word. > Also there is something to be said about not comparing yourself too much > to your competition in the commercial world though much of this doesn't > really apply here in the FOSS world. What I would like to see, however, > are two things: > > 1) A maintained features card comparing FOSS databases. We could add a > feature to the list called "Strict data integrity enforcement." > 2) A maintained features card comparing PostgreSQL and commercial > databases.RDBMS's. Agree here. But I doubt it should be placed on the official site --- there are several unofficial ones, and the prominent link from postgresql.org should be sufficient. ;)
Chris, > The varchar primary key idea (which I think is probably the best > solution) is certainly normalized, but it is also certainly inefficient > disk-wise. Only if you're real short on RAM. Tiny lookup tables tend to get cached in the shared buffer cache and stay there. Your only real overhead is if the application has dozens of ENUMs in a query, causing the number of joins to exceed the number the plannner can plan well. Otherwise, you're preaching false optimization. Overall, I'd say that this is really a waste of time compared to the kind of things you *could* be doing to make converting from MySQL easier, like updating and maintaining the database conversion scripts, writing substitutes for last_insert_id and replace into, or (best of all) writing a detailed "PostgreSQL for MySQL Users" guide. I personally have converted 3 production applications from MySQL to PostgreSQL, and encountered two total ENUM columns in the process. -- Josh Berkus Aglio Database Solutions San Francisco
On Wed, Jul 27, 2005 at 07:21:57AM -0500, Bruno Wolff III wrote: > On Tue, Jul 26, 2005 at 20:59:11 -0700, > Jeff Davis <jdavis-pgsql@empires.org> wrote: > > > > Also, I think what's more important to MySQL than pretty much anything > > else is that slashdot uses MySQL and everyone knows it. If somehow > > I thought that was good promotion for databases other than MySQL. > Slashcode is not known as being a great piece of code. I see errors > returned occasionally (probably less than 1 / 1000 page loads) and > I see complaints that it does not generate standard html, but I haven't > personally looked at what a standards checker says about its output. I think the most informative thing that could be done with sites like this (livejournal is another one that comes to mind) would be to show the difference obtained by migrating to PostgreSQL, both in terms of improved performance and code simplification. I know LJ has a lot of extra (ugly) code meant specifically for scaling, because they have to run something like 30 database servers to try and meet demand. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Wed, Jul 27, 2005 at 09:40:27AM -0700, Josh Berkus wrote: > Chris, > > > The varchar primary key idea (which I think is probably the best > > solution) is certainly normalized, but it is also certainly inefficient > > disk-wise. > > Only if you're real short on RAM. Tiny lookup tables tend to get cached in > the shared buffer cache and stay there. Your only real overhead is if the > application has dozens of ENUMs in a query, causing the number of joins to > exceed the number the plannner can plan well. Otherwise, you're preaching > false optimization. The issue isn't the lookup table; the issue is the space (and I/O) in the main table. > Overall, I'd say that this is really a waste of time compared to the kind of > things you *could* be doing to make converting from MySQL easier, like > updating and maintaining the database conversion scripts, writing substitutes > for last_insert_id and replace into, or (best of all) writing a detailed > "PostgreSQL for MySQL Users" guide. I personally have converted 3 production > applications from MySQL to PostgreSQL, and encountered two total ENUM columns > in the process. Absolutely; somehow that got lost in the thread. Are the database migration scripts not actively maintained? -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Jim, > Are the database migration scripts not actively maintained? Nope. Tom and I dumped stuff out of Contrib into GBorg a while ago, but it's not been touched since. If you want to own it (and move it to pgFoundry) it's all yours. -- Josh Berkus Aglio Database Solutions San Francisco
Jeff Davis wrote: > I mostly agree, but I don't think we can dismiss enum completely. > After all, boolean is pretty much enum(false,true), and nobody would > advocate removing that type. I think you can make the mathematical argument that enums are valid and useful. I'm not going to do that here, but some thoughts: As you point out, any scalar type is really just a set of conveniently chosen symbols that are made interesting by functions and operators. In traditional programming languages as well as in the MySQL case, "enums" are just a short-hand way to define such a scalar type without any interesting operators. Single column tables that merely serve to prove the existence of a concept are valid if those concepts are part of your data model (who are my customers?) but not if they are part of the intrinsics that you base your data model on (these are the colors existing in the physical world). The question is where you draw the line. PostgreSQL gives you a default line. In don't think you can operate completely without any line. -- Peter Eisentraut http://developer.postgresql.org/~petere/