Обсуждение: putting plproxy in pg_pltemplate

Hi

Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?


-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training

On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
> Should we put some externally managed languages , like pl/proxy also in
> pgtemplate, so that CREATE LANGUAGE would work on them ?

This has been rejected several times before.  See:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00050.php

Peter Eisentraut <peter_e@gmx.net> writes:
> On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
>> Should we put some externally managed languages , like pl/proxy also in
>> pgtemplate, so that CREATE LANGUAGE would work on them ?

> This has been rejected several times before.  See:
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg00050.php

Note that there's nothing stopping a DBA from putting new entries in
pg_pltemplate within his installation.  Peter's points are valid reasons
why we should be wary of putting entries into our distribution --- it's
hard to control this sort of stuff over the timescale of a PG major
release.  But per-installation it doesn't seem unreasonable.
        regards, tom lane

Excerpts from Tom Lane's message of vie jul 16 12:49:25 -0400 2010:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
> >> Should we put some externally managed languages , like pl/proxy also in
> >> pgtemplate, so that CREATE LANGUAGE would work on them ?
> 
> > This has been rejected several times before.  See:
> > http://archives.postgresql.org/pgsql-hackers/2009-01/msg00050.php
> 
> Note that there's nothing stopping a DBA from putting new entries in
> pg_pltemplate within his installation.  Peter's points are valid reasons
> why we should be wary of putting entries into our distribution --- it's
> hard to control this sort of stuff over the timescale of a PG major
> release.  But per-installation it doesn't seem unreasonable.

Since a week ago, PL/php ships a small install.sql script that adds a
pg_pltemplate entry.  This seems easy enough for the DBA.

Le 16 juil. 2010 à 13:13, Hannu Krosing <hannu@2ndquadrant.com> a écrit :

> Hi
>
> Should we put some externally managed languages , like pl/proxy also in
> pgtemplate, so that CREATE LANGUAGE would work on them ?

I still  to manage an extension patch. It should be easy for plproxy author (hi Marko) to care for pltemplate entry, I
hope

--
dim