There are a few times when I work with PostgreSQL when I wish it was able to do some things that neither it nor other relational databases are able to do at present. In my view (and I will defend each of these feature requests), these all fit well within a relational db centric world.
3: XML/JSON to tuple type
One of the problems that one runs into in a stored-procedure centric application is managing input and output of an application. An ability to convert XML or JSON to a tuple type (remember that tuples can have members that are tuples, or arrays of tuples). The formats are semantically equivalent, so why not allow for conversion?
2: Nested Namespaces
Managing hundreds or thousands of stored procedures can be a problem in a flat namespace. We end up having to semantically create hierarchical function names or hierarchically named namespaces in a flat namespace world. Even if one cannot do it for tables, there ought to be some way to do this for functions.
Part of the problem here is that the SQL standards give semantic value to different namespace lengths, so this would have to be solved. It is not an easy problem to solve and it may not have a solution. Perhaps a package delimiter within a namespace would be helpful? Maybe a character like# or $?
1: Rich Declarative Constraints for Accounting Applications
It seems strange to me that accounting applications have been one of the primary uses of RDBMS's since their inception, and yet there is no type of declarative constraint to handle ensuring that transactions are balanced.
Whether a transaction is balanced or not is fundamentally a set-based operation. A transaction is balanced when the sum of the debits of the rows in each transaction is equal to the sum of hte credits of the rows in each transaction. In LedgerSMB, debits are negative amounts, and credits are positive amounts (they are just presented to the user as fundamentally different). So I would like the ability to do something like:
CHECK FOR EACH TRANSACTION (SUM(amount) = 0) GROUP BY trans_id;
Part of the problem I suppose is that getting this right in a row-locking environment is hard. However, in an MVCC environment it should be possible to check if this constraint matches the deleted and inserted rows, and if it does (0 + 0 = 0), we know we are balanced (deletions would only happen for unapproved transactions, i.e. ones that have not yet hit the books). Such a check would only fire once per transaction, and only check rows modified by the transaction. It therefore shouldn't be problematic in the way an aggregate check would be over the entire table.
The other two are nice, but if PostgreSQL could do this very well, it would be the king of databases for accounting software, and I am sure they feature would find new uses elsewhere.
So, what's on your list?