Re: Generalized concept of modules

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> 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.

No, it needs to be a separate directory, and the reason is that SQL
scripts are architecture-independent and belong under the share/
directory not the lib/ directory. This is a minor point, but the
packagers will scream at us if we get it wrong.

> 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.

I think I'd sooner keep it decoupled from transactions, which means you
need both a BEGIN MODULE xxx and an END MODULE xxx. Also, a module
developer might want to go back and add more stuff to an existing
module. So there should be separate commands:
CREATE MODULE xxx;
BEGIN MODULE xxx;
... anything created here belongs to the module
END MODULE xxx;
An alternative possibility is to make it work like schemas: you set
a GUC variable to indicate that created objects should be associated
with that module. This might be the best choice since it avoids having
two very different ways of doing very similar things.

(Come to think of it, what is the relation between modules and schemas
anyway? Should a module's objects be required to be in schemas also
owned by the module? If not, what happens when you try to INSTALL a
module whose objects lived in a schema you don't have? This gets back
to the fact that we don't have a very nice answer for installing
existing contrib modules into user-chosen schemas.)

>> 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.

I think we're talking at cross purposes. It sounds like you're thinking
about "how do I remove one object in a module?" AFAICS you just drop it.
What I was wondering was what is pg_dump's behavior. ISTM we want two
modes:

* normal behavior: dump module objects as "INSTALL foo" commands. Do
not dump any objects that are owned by a module; assume they will be
created by the INSTALL. Use the dependency chains to make sure that
INSTALL commands are ordered properly relative to everything else.

* "dump module foo": dump the module object as a CREATE MODULE command,
and then dump creation commands for all the objects that are owned by
it. Ignore all else. This is an easy way to generate an updated module
definition script.

Something that's not at all clear to me is object ownership. Should
objects belonging to a module be marked as being owned by the person
executing INSTALL, or should module dump/install try to preserve
original ownership? I think in most scenarios trying to preserve the
original ownership is wrong, since commonly INSTALL will be used to
transfer objects to new databases where the original owner might not
exist at all. But it's a bit non-orthogonal.

Also, what privileges are needed to execute either CREATE MODULE or
INSTALL? Conservative design would say superuser-only, but I can't put
my finger on any specific reason for that, at least if none of the
contained objects need superuser privs to create.

regards, tom lane