On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus <josh@agliodbs.com> wrote:
> 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.
This is not a fun area in which to try to be exactly like Oracle.
Just to take one example, the whole package is created and dumped as a
single object, with all of its contained functions *and their
comments*, including the exact position of those comments, such as
inside the argument list to document what particular arguments are
supposed to do. We've worked out a (partial) solution to that problem
in Advanced Server, but it's not perfect, and it limits the ability to
implement other features that PostgreSQL users would probably expect,
like being able to add a function to a package after-the-fact.
PostgreSQL has a certain cleanliness of design that comes from doing
things in a way that makes sense from first principles, rather than
the way that other people may have done it. I'm not prepared to say
that a $184B company made a bad design decision here - it certainly
seems to have worked out for them - but it's not what I would have
picked, and it's not a very good fit for other design decisions we've
made in PostgreSQL already.
All-in-all, I'm pretty happy with our EXTENSION system as a way of
loading code (and SQL function definitions) in a modular way. It's
not perfect, but it's definitely made my life as a developer easier.
There are some things you can do with an Oracle package but not a
PostgreSQL extension, but there is an awful lot of overlap, too. I
doubt we'd want to duplicate all that machinery just for compatibility
reasons.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company