Skip site navigation (1) Skip section navigation (2)

Re: contrib function naming, and upgrade issues

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Robert Haas <robertmhaas(at)gmail(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-23 17:44:14
Message-ID: 200903231844.18248.dfontaine@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-23 17:56:22
Subject: GIN fast-insert vs autovacuum scheduling
Previous:From: Tom LaneDate: 2009-03-23 15:38:05
Subject: Re: GIN, partial matches, lossy bitmaps

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group