[ moving this thread to -hackers ]
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". 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.
> 1. When given the name of an external module, you need to be able to
> find the SQL commands needed to make it work.
No problem, the name is the name of a SQL script file stored in a specific
installation directory.
> 2. You need to be able to tell if something is installed already or
> not.
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.
> With these in place, upgrades across versions of postgres could become
> a lot easier. People using tsearch2 now would get only "INSTALL
> tsearch2" in their dumps and when they upgrade to 8.2 they get the new
> definitions for tsearch using GIN. No old definitions to confuse people
> or the database. (Note: I'm not sure if tsearch would be compatable at
> the query level, but that's not relevent to the point I'm making).
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.
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?
regards, tom lane