Management tool support and scalibility - Mailing list pgsql-hackers

At my old job, we used PostgreSQL exclusively.  I was doing programming,
and it was great.

At my new job I've had a chance to work with SQL Server and Oracle.  I
don't like either of them from a SQL point of view.  They just don't
compare (at least for what should be easy stuff, like dates).  However,
they did have a strong point where I see PostgreSQL lacking at the
moment.

(hint, if you read the subject, you've guessed it)

E.g., Oracle 8i had a very nice management console (and from the glimpse
of 9i I got, it's even better).  You could look at things like database
schemas via a tree view, database physical layouts, user information,
and connection information.  (I don't have it in front of me at the
moment, so I'm sure there is more.)  In particular I was very interested
in the ability to view not only what query a connection was doing, but
which operations it did that took a long time to process (full table
scans, etc), which one it is working on now, and how long that one will
take.  I know a while ago someone was working on a way to get similar
kinds of information by attaching to the backends via gdb or something
equally dangerous/hackish/error-prone.  When would such an ability be
put into the system itself?  (I believe Oracle does it through system
tables, which I would think might be good for PostgreSQL, as it would be
hard, and slow, to query each backend every time.)

The other ability that Oracle had that I was impressed with was the
ability to do partitioning.  You could break a database up into pieces
and put them on, say, different drives, files, whatever.  This seems
like a good idea, and one I don't believe PostgreSQL has now.  I suppose
if you wanted to put a single table on another drive, you could move it
and symlink it, but that sounds like another dirty hack.  The other
thing it could do was take a single table and partition it into separate
physical files based on ranges in a column.  This could be used for
archiving, for example.

I know that there exist some pretty nifty third party solutions for
distributed and/or replicated databases (as listed on freshmeat.net),
but having a separate program responsible for it seems like a bad idea
for maintenance.

By now you are probably saying 'If you want these features, why don't
you implement them?'.  Well, I really wouldn't know where to begin. 
I've been on this mailing list since last July with thoughts of working
on PostgreSQL, but more than anything it's convinced me that I wouldn't
know where to begin. ;{  I've purused the source and even read a few of
the interals documents, but I still don't think I would know what really
needs to be done.  (Not to mention that this isn't a short list of easy
features.)

What are all your thoughts on these items?  Is PostgreSQL not at a point
where it should be thinking of this stuff?  I know you're adding some
new features and tweaks to the engine still, but I think the above
features would make alot of people more interested in PostgreSQL.  Many
people still think that open source products are just not
user-friendly.  I think these features would go a long way towards that.

--Kevin