Re: contrib function naming, and upgrade issues

On Monday 23 March 2009 15:43:04 Tom Lane wrote:
> I think the way most people are envisioning this is that a module is a
> set of SQL objects (functions, types, tables, whatever). Whether any
> of those are C functions in one or more underlying .so files is not
> really particularly relevant to the module mechanism.

Fine, that's what I wanted to call an extension in order not to change the
meaning of module. I'll edit the proposal on the wiki later on tonight.

> It should be possible to have a module that doesn't contain any C code,
> so the concept of a defining function does not look good to me. A
> defining SQL script is the way to go.

Agreed here.
I added some special SQL syntax on my proposal in order for the module author
to be able to provide some advanced notions (dependencies, version, etc).

I still think that using this special syntax around custom sql has advantages,
namely that help solving the module altering facility and module variable
handling.

Module variable are needed by e.g. pljava for its classpath setting, which is
meant to change depending on the caller from what I've been told.

ALTER MODULE pljava SET classpath = 'some value here';

Of course, as hinted by Peter, the variables here are not GUCs.

> The only way that the underlying .so file(s) become relevant is if you
> are trying to make this a *packaging* mechanism that can actually
> deliver and install the set of files required to implement a module.

What I'm proposing in the WIP wiki page is to propose a source based packaging
based on PGXS (just some glue around it to fetch the right tarball from
command line without bothering, then run make and make install, can come much
later).
Binary packaging could then be made to work by packagers, based on this.

What I like about this optional tool is the fact that the -core distribution
could then publish extra contribs in a central trusted location, such as
http://modules.postgresql.org/.
Source based only distribution there, hassle-free, allowing -core to stamp
e.g. plproxy as a trusted module for PostgreSQL. Minor releases policy would
have to be talked about, of course.

> I don't think that's a good idea; not least because systems tend to
> already have their own packaging mechanisms, and we don't need to invent
> another. I think "module" should just be a SQL-level concept and not be
> concerned with how the files it needs arrive where they're needed.

Well, maybe just complaining at module "creation" time (that's when you run
the SQL script possibly containing CREATE OR REPLACE MODULE ... $$ <sql> $$)
would be enough as far as .so dependency is concerned.
The error message would of course come from the first create function language
C referring to the non existent file, which would trigger a rollback.

Is that roughly what you have in mind?
--
Dimitri Fontaine
Architecte DBA PostgreSQL