Comments for Being at the MySQL User Conference: how Postgres fits in

[phinjensen]

Comments for https://www.endpointdev.com/blog/2009/04/being-at-mysql-user-conference-how/
By Selena Deckelmann

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: Ethan Rowe
date: 2009-04-30T14:42:00-04:00

Thanks for the post, Selena.

My distaste for MySQL cannot take any schadenfreude in the MySQL community's plight; the free software enthusiast in me is too upset at a major free software player potentially getting kicked in the butt by one of the organizations the products/policies of which played a significant role in my own free software evolution.

But, to the Postgres love-in: I love Postgres for quite different reasons. It's feature set is fantastic. Is it "complete"? No. I would like to see things like PIVOT. I would like to see something that handles adjacency lists more effectively than what's out there. I would like to see servers in recovery mode able to handle SELECTs for easier, effectively master/slave replication. And so on. But the feature set that's there is beautiful. As an application developer who tries to make the most of each layer of the stack, there's simply no comparison between Postgres and the other free offerings. Given the policies, costs, bloat, and general unpleasantness of Oracle, I would much prefer the use of Postgres to Oracle. To say nothing of SQL Server.

DDL in transactions? Roll-your-own group aggregate functions? The rules system giving control over the query tree? Solid referential integrity with years' of support and improvements? I could go on, but I'll stop. Postgres rocks, period.

[phinjensen]

original author: Joshua Tolley
date: 2009-04-30T14:49:00-04:00

To the budding patch reviewer, the PostgreSQL wiki's page on patch review HOW-TO is an excellent resource. You don't have to know the PostgreSQL code to do a patch review. There's plenty of work there for someone who doesn't know any C, even. The primary qualification is someone willing to find creative ways to test out new patches.

[phinjensen]

original author: Selena Deckelmann
date: 2009-04-30T15:05:00-04:00

@joshua: Thanks for the link!! I added it to the body of the post as extra encouragement to would-be reviewers.

@Ethan: Regarding pivot have you seen the contrib module "tablefunc"? http://www.postgresql.org/docs/8.3/interactive/tablefunc.html

Yes, transactional DDL is awesome. There are so many features that are awesome. I tend to talk about the people because not many other people in our community do that. And, who the people are that drive a project often play a big role in how a person decides whether or not to throw their support behind a project. I don't think there's anything wrong with that -- the character of the programmers and development team is often reflected in the quality of the code.

And, having spent a little time spelunking in MySQL internals last week, the Postgres code base is absolutely incredible, easy to read and extend. More universities are discovering this and using our code base for their classes -- having students write features that they might contribute back.

[phinjensen]

original author: Ethan Rowe
date: 2009-04-30T15:17:00-04:00

"Our code base".

I live in the Boston area, where the screaming multitudes talk about "our chances" at this or that series, and about how "we" did last season.

When presented with such speech, my tendency is to ignore it or, occasionally, ask if the speaker is on the team.

"Our code base" is a true statement, and thus life can be beautiful.

[phinjensen]

original author: Robert Treat
date: 2009-05-01T15:53:00-04:00

I'm not sure we will have a problem with forks like mysql has, because really we've already been there. Postgres has been forked both for open source projects, commercial distributions, closed source implementations, and for internal use only systems. In fact, there has been at least 20 different versions of Postgres put out over the years, according to the wiki: http://wiki.postgresql.org/wiki/PostgreSQL_derived_databases

I think the thing that has helped the Postgres community is that so far, we haven't had a split of the brain trust that keeps Postgres going. This allows our community to approach the forks with the idea that as long as we/core community keep steam-rolling forward, the forks will generally be a non-issue.

Part of MySQL's issue is that they have no central community pushing things forward right now. In the past, that was always the role of MySQLAB, but between the Sun buyout and now the Oracle purchase, that leadership has wavered. Oracle is still in the best position to reclaim that leadership, but it will take some time (6 months), and they will need a more recognizable presence within the community going forward.

[phinjensen]

original author: Selena Deckelmann
date: 2009-05-01T17:26:00-04:00

@robert: Good points.

What I'm pointing out is that we haven't grown to the size of MySQL, and thus haven't had an opportunity to have, say, 100 paid developers stop working on the core code and fork an entirely new product.

Sure, the issues that lead to the forks are not necessarily ones that Postgres has. However, its good to pay attention -- both to highlight counter-examples, and so that we can feel good about continuing to do things that work for us.