Table inheritance already exists, the problem is that its generally not a great idea for databases. I believe the general consensus from much of the community is they wish Postgres didn't have it. I don't foresee many improvements to it in the near term, but also very hard to predict what will come out of it as if someone wants to scratch that itch it has a chance of getting in.

What is wrong with table inheritance, given it makes for a good partitioning mechanism? Is it being misused in other areas?

I actually like table inheritance. However there are all kinds of quite annoying cases about it and it gets misused in many cases.

What it works for really well

Table inheritance works really, really well for enforcing consistent interfaces to repeatedly used pieces of information which are independent for referential integrity purposes. For example, we've all seen horrors involving global notes tables with umpteen join tables.... Inheritance provides a very clean solution to that problem: have an abstract notes table (which can double for query purposes as a global notes table) and worker tables which have foreign keys which attach specifically to other tables.

For example, in LedgerSMB we have a note table, an invoice_note table a eca_note table (notes for customer/vendor agreements), and more. The nice thing is, the tables all have the same structure and can be managed structure-wise as if they were a single table.

For example, an alter table statement on note can affect all sub-tables in many cases (other than unique constraints, primary or foreign keys, etc). If I want to add a virtual column for full text searching, I can do this with a single function as follows:

    CREATE OR REPLACE FUNCTION tsvector(note) 
    RETURNS tsvector
    language sql immutable as
    $$ SELECT to_tsvector($1.subject || ' ' || $1.note); $$;

Then eca_note.tsvector will just work (subject to limitations of this syntactic feature of PostgreSQL). I could even index the output of the function on any note subtable.

What It Does Not Work For

So inheritance is often sold as a way of tracking part/whole relationships and other type/subtype problems. The problem is that these currently break down where you need referential integrity enforcement across an inheritance tree. Consequently, while I see inheritance as a really, really useful feature, it is a feature that is largely useless for the problems it was originally intended to solve. Now, it is getting better (9.2 added NOINHERIT constraints, which allow you to apply different check constraints to parent and child tables, useful if you want to forbid all inserts to the parent table), but the really big problems have to do with the inability to properly inherit unique indexes, and therefore not to referential integrity enforcement against a whole inheritance tree.

In general in these cases, you are better off with a single table, and designing a structure without table inheritance to model the information.

By this I assume you mean "inherits primary key/foreign keys properly?"

The problem I think is that this is likely to force some significant redesign of indexes. It isn't a trivial problem to solve.