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
signature.asc
Description: This is a digitally signed message part.
