Skip site navigation (1) Skip section navigation (2)

Usability, MySQL,, gborg, contrib, etc.

From: pgsql(at)mohawksoft(dot)com
To: pgsql-hackers(at)postgresql(dot)org
Subject: Usability, MySQL,, gborg, contrib, etc.
Date: 2004-04-25 21:15:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
A sort of debate started by Bruce about what MySQL does better vs what
PostgreSQL could do, then there was a thread about removing "/contrib"
from the main download, and a few other posts.

I don't think these are unrelated. They all fall under the umbarella of
"How does a new user come to use PostgreSQL?"

I have come to believe it is a number of issues, it isn't just the site,
it isn't just the setup, it isn't whether or not contributed modules are
easy to find, I think it is all of these.

(1) I think the PostgreSQL web presence has been lacking for some time. I
am not a web developer myself, but I do know that the PostgreSQL site does
not seem to look and feel like other sites. The new site is better than
before, but I think it still needs some more standardization with the rest
of the web.

There are a lot of "usability" issues that can be fixed easily. Links to
the left, fluff items to the right, main message in the middle, symplified
menus, etc. Again, while I'm not a web designer, I have a small moch-up of
something I think would have more visual "clues" to new users at

(2) Removing the "contrib" directory in the main download. I think this is
a good idea, but it means that we need to make it easier to make
extensions. I write a lot of extensions and I have a standard Makefile for
building them. (Granted I have to change it periodically for different
versions) You have to specify the PostgreSQL build directory to build an
extension. It isn't clear to me if there is a way to build an extension to
PostgreSQL without having built PostgreSQL first. It would be nice if
there were a standardized set of extension headers and a well documented
process to make an extension. Then we could focus on a standard API. :-)

(3) Configuration. What can I say, power users edit postgresql.conf, start
scripts, pg_hba.conf, etc. I think it can safely be said, that we need to
show non-power users the light. For this, there needs to be an
application, in some portable scripting language, that can configure
PostgreSQL. Maybe it is in the form of a web server like Samba's SWAT
utility, I don't know (A SWAT type utility could run as the PostgreSQL
user for the correct rights), but users need this. I don't think the
typical debate of "GUI tool aren't really easier" or "That's just bloat"
or "Do we even want these users using PostgreSQL" are relevent. If we want
to increase usership, this is a requirement.

(4) Blessed projects, lets play favorites. Lets find good and meaningful
extensions on gborg and ./contrib and work with the authors and make them
part of the PostgreSQL "environment."  Projects like, replication, .NET
service provider, ODBC, pgAdmin, etc. are important and users need to find
them close to PostgreSQL's main location.

(5) Programming languages. We need to make a programming language standard
in PostgreSQL. plpgsql is good, but isn't someone working on a Java
language. That would be pretty slick.

(6) In keeping with item #4, lets make some Binary distributions and make
those available on the mirrors. Think about how a Windows user tries
software: Click on a site, install, and run. I could update my Windows
installer and console system and create a zipped install. I know there are
rpms and debs out there, but if you look at programs like mozilla and
realplayer, they have a pretty good installer. Maybe we could use the
Mozilla installer? What happend to the Great Bridge installer?

When all is said and done, I think the PostgreSQL project lacks a "Product
Management" group which steers the public perception and defines
usability. This is something *all* other systems have, including MySQL.

If we want to make PostgreSQL a wildly popular product, there will be some
pain. There should be a "Product Management" group. The leader(s) of this
group should be chosen carefully, as he (they) must be free to define what
PostgreSQL is. They must have a good feel for product development and
understanding of the underlying technology, but not be so techie that we
don't address the issues intended. They must be able to rally the troops
and direct development efforts. Lastly, he (they) must have the confidence
of the core hackers, as it is likely that there will be disagreements with
the direction of PostgreSQL, and it wouldn't work if "Product Management"
couldn't actually manage what the product was because nobody listened.

Is anyone really ready for this sort of commitment?


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-04-25 21:21:47
Subject: Re: thread_test.c problems
Previous:From: Bruce MomjianDate: 2004-04-25 20:41:27
Subject: Re: [HACKERS] What can we learn from MySQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group