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

Re: contrib function naming, and upgrade issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: 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>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-23 14:43:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> On Sunday 22 March 2009 22:46:20 Tom Lane wrote:
>> You really haven't convinced me that this is anything but
>> overcomplication.

> Thinking about it some more what could be convincing is that an extension 
> could be made of only SQL, with no module (.so) (I have a case here).

> If a single .sql file can be seen as an extension, I'd want to avoid naming it 
> the same as the .so file itself. Having the term "module" refer either to a 
> single .so (or .dll), or a .so with an accompanying .sql file to install it, or 
> even just the SQL file... would add confusion, methinks.

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.

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.

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

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-23 15:38:05
Subject: Re: GIN, partial matches, lossy bitmaps
Previous:From: Greg Sabino MullaneDate: 2009-03-23 12:41:43
Subject: Re: Have \d show child tables that inherit from the specified parent

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