Re: Attention PL authors: want to be listed in template table? - Mailing list pgsql-hackers
| From | Thomas Hallgren |
|---|---|
| Subject | Re: Attention PL authors: want to be listed in template table? |
| Date | |
| Msg-id | thhal-0Nhb6A6u68LQp8ys2VO4EbTzstN/pjo@mailblocks.com Whole thread Raw |
| In response to | Attention PL authors: want to be listed in template table? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Attention PL authors: want to be listed in template table?
Re: Attention PL authors: want to be listed in template table? |
| List | pgsql-hackers |
Tom,
I assume that the path of the shared library will be somehow relative to
the GUC dynamic_library_path? If not, the lanlibrary should be changed
to "$libdir/libpljava". That requires that PL/Java is installed within
the PostgreSQL distribution.
I also assume that the handler name can be prefixed with a schema name?
All PL/Java support functions reside in the sqlj schema.
If my assumptions are correct, then please add:
{ "java", true, "sqlj.java_call_handler", NULL, "libpljava" },{ "javaU", false, "sqlj.javau_call_handler", NULL,
"libpljava"},
The validator for PL/Java will have to wait until 8.2.
Regards,
Thomas Hallgren
Tom Lane wrote:
> I've committed changes to implement the cut-down form of this proposal:
> http://archives.postgresql.org/pgsql-hackers/2005-08/msg01185.php
> discussed here:
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg00138.php
>
> Barring further changes, we'll have a hard-wired template list for 8.1
> and a real system catalog in 8.2. So there's a choice now for PLs that
> are not part of the core distribution: do you want to be listed in the
> hard-wired template?
>
> The advantages of being listed are:
>
> 1. Reloading old dumps that involve your language should be easier,
> since problems like version-specific paths to shared libraries will
> go away.
>
> 2. Your PL support functions will end up in pg_catalog instead of
> the public schema, which will please people who'd like to remove public
> from their installations.
>
> The main disadvantage I can see is that you won't easily be able to
> change your PL creation parameters (eg, add a validator function)
> over the lifespan of the 8.1 release. So depending on your development
> roadmap you might think this a bad tradeoff.
>
> If you want to be listed, let me know. What I need to know to list you
> is values for this table:
>
> typedef struct
> {
> char *lanname; /* PL name */
> bool lantrusted; /* trusted? */
> char *lanhandler; /* name of handler function */
> char *lanvalidator; /* name of validator function, or NULL */
> char *lanlibrary; /* path of shared library */
> } PLTemplate;
>
> As examples, the entries for the core PLs are
>
> { "plpgsql", true, "plpgsql_call_handler", "plpgsql_validator",
> "$libdir/plpgsql" },
> { "pltcl", true, "pltcl_call_handler", NULL,
> "$libdir/pltcl" },
> { "pltclu", false, "pltclu_call_handler", NULL,
> "$libdir/pltcl" },
> { "plperl", true, "plperl_call_handler", "plperl_validator",
> "$libdir/plperl" },
> { "plperlu", false, "plperl_call_handler", "plperl_validator",
> "$libdir/plperl" },
> { "plpythonu", false, "plpython_call_handler", NULL,
> "$libdir/plpython" },
>
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
pgsql-hackers by date: