putting plproxy in pg_pltemplate

Started by Hannu Krosingover 15 years ago5 messages
#1Hannu Krosing
hannu@2ndquadrant.com

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

#2Peter Eisentraut
peter_e@gmx.net
In reply to: Hannu Krosing (#1)
Re: putting plproxy in pg_pltemplate

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

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#2)
Re: putting plproxy in pg_pltemplate

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

#4Alvaro Herrera
alvherre@commandprompt.com
In reply to: Tom Lane (#3)
Re: putting plproxy in pg_pltemplate

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.

#5Dimitri Fontaine
dfontaine@hi-media.com
In reply to: Hannu Krosing (#1)
Re: putting plproxy in pg_pltemplate

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