Can You Pass Me a Fork?

I ran across Steve Mallett’s [ blog post] about the new [ EnterpriseDB] [ press release] regarding thier new Oracle compatible version of PostgreSQL, which only further pushed home the idea to me that the PostgreSQL project is forking. Not in the classic sense, there wern’t any flame wars by core members and no big march of a bunch of developers to leave the project, but we certainly have a [ couple] of forks running around even though they might not be advertising themselves as such. The big question is what does this mean for the PostgreSQL community? So far I have seen more upside than downside, since all of the companies that are involved have devoted resources back into the community, but I am starting to see some cracks. A week or so back I noticed that there were some folks talking about table partitioning within postgresql on both the pgsql-hackers list and the bizgres list, so I replied to the pgsql-hackers thread to mention this fact. This led to a little bit of a [ “Why are discussing postgres features over there when we do development over here?”]. A valid question, though no big deal on its own, however the bizgres folks are also talking about having thier own release schedule, so that they can get table partitioning to the market asap even if PostgreSQL core isn’t ready to go with it, and that could certainly lead to divergent codebases. Another example? EnterpriseDB lists one of thier compatabilty enhancements as allowing column based triggers in PostgreSQL, which is something that 8.0.x doesn’t have. The thing is, this is [ being worked on] for 8.1, by Greg Mullane. I’ve talked with him about his patch a couple of times which is why this jumped out at me. So now I’m curious what EnterpriseDB has coded up, and when (or if) it will be donated back to PostgreSQL core, and why they might think it is a good thing to have people doing duplicate work on a feature? And here’s hoping those features don’t end up syntactically different! I think I prefer the way [ Pervasive] is doing things right now. They have made too many big, splashy claims, and haven’t contributed any big batches of code, but they have offered up support with some back-end hardware for PostgreSQL web folks, and so far they are keeping in step with the PostgreSQL core project’s releases. This just seems better for the project, which is really just hitting it’s stride, and doesn’t need any more confusion about what [ features] are [ included ] [ where].