Re: contrib function naming, and upgrade issues

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