Re: Attention PL authors: want to be listed in template table?

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Attention PL authors: want to be listed in template table?
Date: 2005-09-07 05:42:12
Message-ID: thhal-0Nhb6A6u68LQp8ys2VO4EbTzstN/pjo@mailblocks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-09-07 08:02:39 Testing for a shared library
Previous Message Jim C. Nasby 2005-09-07 05:38:44 Re: [HACKERS] How to determine date / time of last postmaster restart