Re: pl/pgsql enabled by default - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pl/pgsql enabled by default
Date
Msg-id 13959.1115388848@sss.pgh.pa.us
Whole thread Raw
In response to Re: pl/pgsql enabled by default  (Neil Conway <neilc@samurai.com>)
Responses Re: pl/pgsql enabled by default  (Andrew Dunstan <andrew@dunslane.net>)
Re: pl/pgsql enabled by default  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> But I agree security is not a good argument against enabling it by default.

Isn't it?  Even without anything that we regard as a bug, availability
of a server-side programming language is still a risk factor from the
point of view of any reasonably paranoid DBA.  The denial of service
risk in particular (whether intentional or accidental) goes way up.

Another problem with this proposal is that installations without
shared-library support will stop working entirely.  I suppose we could
get around that by building plpgsql into the core backend instead of as
a shared library, but that will be risky if the other PLs migrate out
--- plpgsql really should be built the same way as the rest of them, so
that it continues to serve as an early warning system for build/link
problems.

Also, your proposal as worded does not seem to mean "installed by
default", it means "installed, period".  How would a DBA who doesn't
want it get rid of it?  If he later changes his mind, how does he
return to a standard configuration (short of initdb)?  We don't really
have support for removing and re-adding built-in functions.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: Stephen Frost
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement