On 09/04/2014 09:02 AM, Craig Ringer wrote: > There are a few things I would like to see, like secure session > variables in PL/PgSQL. Mostly, though, I think talk of "Oracle > compatibility" seems to be something that comes up before the speaker > has really understood what that would mean, and the sheer scope of the > endeavour. > > It's not going from 50% compatible to 80% compatible, it's going from 5% > compatible to 7% compatible. The most used 5% maybe, but still...
However, there are users who want certain features from PL/SQL not for compatibility but because they're useful. For example:
* A "package" concept for encapsulation of multiple procedures, session variables, etc.
* The ability to "compile" functions/procedures for faster execution.
This point is more complex, because bottleneck is not in plpgsql - it is terrible fast against noncompiled pcode interpreted PL/SQL and it is comparable with PL/SQL - due different design. A expression evaluation is slower, partially due using a SQL expression interpret, partially due our arrays and strings are immutable, and any composition are slow. Cost of hidden IO cast is negative too. If we can change it, then we can increase a sped. Almost all from these bottlenecks are out of plpgsql engine. So compilation of plpgsql is myth and it doesn't help and it doesn't need it. It doesn't help with speed.
Pavel
* Autonomous transactions
We'd also like to borrow stuff from other DBMSes, such as multisets. All of the above are worth implementing, even if it means implementing them with different syntax (and mechanics) than PL/SQL.
Sadly, what's prevented us from having "packages" already has been the insistence of potential feature sponsors that they work *exactly* like PL/SQL's packages, which is incompatible with Postgres namespacing. Also, we'd want any "package" concept to be usable with external PLs as well as PL/pgSQL, which necessitates other Oracle-incompatible changes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
