Re: [HACKERS] Enticing interns to PostgreSQL

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