Not sure if this is the right place to request this, but here are some
things I, as a satisfied user of PostgreSQL, would like to see done (and
I'd be glad to help where I can). All of these are just suggestions
geared to the care and feeding of the PostgreSQL user community.
1. Update the comparison chart at
http://www.postgresql.org/comp-comparison.html. This is important for
those of us who must justify our choice of PostgreSQL to clients,
supervisors or funding agencies. Suggestion: add Informix and MySQL and
drop BeagleSQL and MiniSQL.
2. Post a schedule for future releases. This is important for those of
us who want to know when -- if ever -- we can start to consider
PostgreSQL as a solution for projects that require features that are not
yet part of PostgreSQL (e.g. replication), and when we should think
about upgrading our PostgreSQL installations. It is also crucial to let
prospective users know that Postgres is under active development. I
know there is a todo list somewhere but I think the schedule needs to be
more prominent on the web site.
3. Fix the PostgreSQL user gallery (linked from
4. Provide a better feature request method. Mailing lists are a great
start. But I'd like to know how many people are requesting which
features, whether there is a work-around, if there is a documentation or
a terminology issue that causes people to continue to request features
that are already in PostgreSQL, and what people have decided to do
(upgrade to later version, go with another database, redesign their
I think two tables would capture this information: one containing
feature, which release (if any) of PostgreSQL supports or will support
the feature, work-around, documentation issue, and terminology issue;
and the other containing reference to feature, name and address of
person requesting feature, why feature is needed, and how person
resolved the feature request. I assume the PostgreSQL web site can be
backed by a PostgreSQL database. Just to clarify, these tables would
capture feedback from users (via a web form or e-mail messages) in a
more structured and detailed format than a mailing list or the current
todo list, and provide a way for PostgreSQL hackers to "close out"
5. Install a bug tracking system. I guess the todo list is working
pretty well because the quality of the latest release is very good, but
I haven't been able to figure where else to search for things that look
like bugs to me, except against the mailing lists. Often the discussion
of a bug on the (many) mailing lists morphs into something else without
appearing on the todo list and I'm left unsure if the bug has been fixed
or not. As a user relying on PostgreSQL, I'd feel better if the method
used to track bugs was more centralized, transparent and structured.
Maybe some of this stuff can be addressed by the new commercial support
All in all, PostgreSQL is making great strides and works well. Keep up
the good work!