Re: PL/pgSQL 2

2014-09-04 18:29 GMT-03:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus <josh(at)agliodbs(dot)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.
>

If it were possible to mark a function as "private for its extension" that
would be awesome (the opposite would work too, i.e. a way to specify a
public API, meaning the rest is private). For big extensions it's not clear
which functions can be used directly by users of the extension and which
ones are just implementation details.