What I can add is that, if Postgres is to devote resources to a new language, I would plan it with a broader scope. What would attract most users? Would it bring non postgres users to Postgres? What could be one of the killer features of any next version? My trivial answer to most of these questions is: PL/SQL.
By that I suppose you mean "I wish it would act just like Oracle". The problem with such a wish is that a lot of the incompatibilities with Oracle are functions of the core SQL engine, not of the PL. plpgsql already is about as close to PL/SQL as it's possible to get without changing core Postgres behavior --- or at least, that was the original design desire, and I don't think that it's failed in any large degree.
regards, tom lane
It's true that some of the incompatibilities are the core engine, internal functions and so on, and that the plpgsql design goal was to achieve "similarity". But similarity is not code compatibility, and afaik, plpgsql is not code compatible with PL/SQL. Having 1:1 code compatibility, if possible, is a very well first step, only followed by the core functionalities you mention.
If postgres were going for a new language, why not implement one which, having the other suggested functionality, also has 1:1 PL/SQL code compatibility? I'm sure it's no trivial task, but one highly desirable.
It is false expectation - language is only one part .. and plpgsql isn't to far. There are different system of modules, different system of custom aggregates, mainly with PL/SQL is very complex library dbms_xxxx. This library is maybe more complex than current Postgres base.
It is task for commercial project --- not all Postgres users need a Oracle compatibility layer. Next, I am sure, so it is in contradiction to Joel proposal.
