On 5/31/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> >>> Could you serve this as special docstring instead? Eg:
> >>> PG_MODULE(foomodule)
>
> I have no objection to that, and see no real implementation problem with
> it: we just add a "const char *" field to the magic block. The other
> stuff seems too blue-sky, and I'm not even sure that it's the right
> direction to proceed in.
It was not blue-sky, it was handwaving :)
> Marko seems to be envisioning a future where
> an extension module is this binary blob with install/deinstall/etc code
> all hardwired into it. I don't like that a bit. I think the current
> scheme with separate SQL scripts is a *good* thing, because it makes it
> a lot easier for users to tweak the SQL definitions, eg, install the
> functions into a non-default schema. Also, I don't have a problem
> imagining extension modules that contain no C code, just PL functions
> --- so the SQL script needs to be considered the primary piece of the
> module, not the shared library.
I'll later post a list of ideas that we can hopefully agree on
and discuss them further.
> Is it worth adding a module name to the magic block, or should we just
> leave well enough alone? It's certainly not something foreseen as part
> of the purpose of that block. In the absence of some fairly concrete
> ideas what to do with it, I'm probably going to vote keep-it-simple.
Yes, if we want to keep separate SQL for modules then
putting stuff into .so is pointless.
--
marko