Tom Lane wrote:
"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes:
Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
and resolves and calls _PG_init and _PG_fini functions of an extension
module right after/before the pg_dlopen/pg_dlclose calls in the FMGR.
This seems like a reasonably good idea, and we have got uses for at
least the "init" case in most or all of our PLs. It's nominally too
late for 8.2 feature freeze, but I said just a couple days ago that
we shouldn't take a very hard line on that. Does anyone object to
considering this for 8.2?
I don't. We've been porous in the past and I think we should be prepared
to be a bit lenient again, especially since this release is not hugely
feature rich.
One question I have is whether it really works as expected in all cases.
In particular what if the library is "preloaded" into the postmaster?
Both plpgsql and plperl seem to think they might need to make a
distinction between things to do at library load time and things to do
per-backend ... and yet, neither of them *actually* have anything they
need to do per-backend.
I have longterm plans for plperl concerning preloading perl modules,
which might involve the preloaded lib. At the moment it's just a thought
in my head, though.
Also, what about Windows? I assume that DSOs don't remain attached
across the pseudo-fork/exec, will that mess anything up?
Good question.
cheers
andrew
---------------------------(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
match
