On 5/31/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> 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.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to