Re: Generalized concept of modules - Mailing list pgsql-hackers

On Wed, May 31, 2006 at 05:33:44PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > While you do have a good point about non-binary modules, our module
> > handling need some help IMHO. For example, the current hack for CREATE
> > LANGUAGE to fix things caused by old pg_dumps. I think that's the
> > totally wrong approach long term, I think the pg_dump shouldn't be
> > including the CREATE LANGUAGE statement at all, but should be saying
> > something like "INSTALL plpgsql" and pg_restore works out what is
> > needed for that module.
>
> There's a lot to be said for this, but I keep having the nagging
> feeling that people are equating "module" with "shared library", which
> seems far from sufficiently general.  I'd like to see "module" mean
> "an arbitrary collection of SQL objects".

I agree that module is often used interchangably with shared library.
We need to handle the other case too. It would be a lot easier if we
had an example of an SQL only module, since contrib doesn't appear to
have one (at first glance anyway).

> So I think the raw definition
> sought by your "INSTALL" would always be a SQL script, and any shared
> libs that might come along with that are secondary.  The idea of using
> pg_depend to manage UNINSTALL is an excellent one.

Well, in that case I'd like to give some concrete suggestions:

1. The $libdir in future may be used to find SQL scripts as well as
shared libraries. They'll have different extensions so no possibility
of conflict.

2. Create something like "BEGIN MODULE xxx" which starts a transaction
and marks any objects created within it as owned by module "xxx". I
think it should be tied to a transaction level to avoid half installed
things, but maybe people would prefer it to work more like schemas.

> pg_module system catalog.  You'd need this anyway since there has to be
> some representation of the "module object" in the catalogs for its
> component objects to have pg_depend dependencies on.

Ack. "Owned by" in the above sense means that the object depends on the
module. You could do it the other way round (module depends on object)
but that makes it harder to change things manually. DROP MODULE would
work easier too.

> Let's see, I guess pg_dump would have to be taught to ignore any objects
> that it can see are directly dependent on a module object.  What about
> indirect dependencies though?  The exact semantics don't seem clear to me.

At a base level, you could definitly drop the functions. Dropping types
is harder because columns might be using them. Normally we use CASCADE
to specify that.

> Also, this seems to be getting into territory that Oracle has already
> trod --- someone should study exactly what they do for PL/SQL modules
> and whether we want to be compatible or not.  Perhaps there's even
> something in SQL2003 about it?

Probably a good idea...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.