Re: Installing PL/pgSQL by default

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > Before we go too far with this, I'd like to know how we will handle the
> > problems outlined here:
> > <http://archives.postgresql.org/pgsql-hackers/2008-02/msg00916.php>
>
> Hm, I think that's only a problem if we define it to be a problem,
> and I'm not sure it's necessary to do so. Currently, access to PL
> languages is controlled by superusers. You are suggesting that if
> plpgsql is installed by default, then access to it should be controlled
> by non-superuser DB owners instead. Why do we have to move the
> goalposts in that direction? It's not like we expect that DB owners
> should control access to other built-in facilities, like int8 or
> pg_stat_activity for example. The argument against having plpgsql
> always available is essentially one of security risks, and I would
> expect that most installations think that security risks are to be
> managed by superusers.

I installed PL/pgSQL by default via initdb with the attached patch. The
only problem is that pg_dump still dumps out the language creation:

CREATE PROCEDURAL LANGUAGE plpgsql;
ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres;

What is odd is that I used the same process that initdb uses to create
other objects. Does anyone know why this is happening?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +