Re: [HACKERS] Enticing interns to PostgreSQL - Mailing list pgsql-advocacy
From | Robert Treat |
---|---|
Subject | Re: [HACKERS] Enticing interns to PostgreSQL |
Date | |
Msg-id | 200507252021.03919.xzilla@users.sourceforge.net Whole thread Raw |
In response to | Re: [HACKERS] Enticing interns to PostgreSQL ("Jim C. Nasby" <decibel@decibel.org>) |
List | pgsql-advocacy |
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
pgsql-advocacy by date: