Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I assume that the path of the shared library will be somehow relative to
the GUC dynamic_library_path?
Well, whatever you put in the template is what will be in the probin
field of the support functions. I suppose it does not *have* to use
$libdir, but I would definitely recommend using $libdir rather than
depending on dynamic_library_path.
I'm not I understand this. The default setting for the
dynamic_library_path is $libdir, isn't it? So why have another hardwired
setting here? Wouldn't it be better if all PL's used the
dynamic_library_path setting at all times?
I also assume that the handler name can be prefixed with a schema name?
All PL/Java support functions reside in the sqlj schema.
Not if you use the template facility, they won't. The handler and
validator are hard-wired to live in pg_catalog under this scheme.
Ok. That's fine. They're not covered by the SQL standard anyway. I have
a lot of other "support functions" for managing jar files, classpath,
etc. in the database. They all live in the sqlj schema but they will not
be affected by this.
The validator for PL/Java will have to wait until 8.2.
Do you want to drop in a stub? It's only a one-line function.
Yes, that's a good idea. I'll call them "java_validator" and
"javau_validator" respectively.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
