Thread: 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