Re: Including PL/PgSQL by default - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Including PL/PgSQL by default
Date
Msg-id 46e43367198adcdaa096aea7d1081a5b@biglumber.com
Whole thread Raw
In response to Re: Including PL/PgSQL by default  (Andrew Sullivan <ajs@crankycanuck.ca>)
Responses Re: Including PL/PgSQL by default  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


>> The way I intended to do it would indeed allow it to be undone
>> simply by executing 'drop language plpgsql' in template1.

> Why isn't it enough that administrators can do CREATE LANGUAGE
> plpgsql in template1?

Because people do not have the rights, or the knowledge, or both. I'm
glad most packagers are choosing to enable it by default, because it
can be a real pain for applications like MediaWiki, which has a point
and click GUI installation that is made extraordinarily harder by
having to explain: what plpgsql and tsearch2 are, how to install them,
what a "superuser" is, what they should tell their hosting provider, etc.

I'm not sure I understand the security implications of turning plpgsql on:
has there been some security concerns in the past? Does having access
to plpgsql really faciliate an attacker that much above what they might
already be capable of without it? It seems quite trivial to write a
function in sql that ties up resources just as effectively as plpgsql.

+1 on installed by default, in case it wasn't clear from the above. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200802202019
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAke80bUACgkQvJuQZxSWSsgH/ACcD2A/BjKqT3DHWsb7ybKWGL0H
AEYAoMKcvd+tBhyB4NpFzOMi5nT7Y6zq
=dP0/
-----END PGP SIGNATURE-----




pgsql-hackers by date:

Previous
From: "Dawid Kuroczko"
Date:
Subject: Re: Permanent settings
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Permanent settings