Dimitri Fontaine <dfonta...@hi-media.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
