Re: Including PL/PgSQL by default

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Including PL/PgSQL by default
Date: 2008-02-21 01:20:17
Message-ID: 46e43367198adcdaa096aea7d1081a5b@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200802202019
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-02-21 02:14:27 Re: Permanent settings
Previous Message Dawid Kuroczko 2008-02-21 00:12:33 Re: Permanent settings