Re: pl/pgsql enabled by default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/pgsql enabled by default
Date: 2005-05-06 14:14:08
Message-ID: 13959.1115388848@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2005-05-06 14:15:44 Re: [pgsql-advocacy] Increased company involvement
Previous Message Peter Eisentraut 2005-05-06 13:51:48 Re: [pgsql-advocacy] Increased company involvement