Management tool support and scalibility

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