Re: pl/pgsql enabled by default

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-07 04:39:38
Message-ID: 427C468A.7080106@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> The denial of service risk in particular (whether intentional or
> accidental) goes way up.

Does it really go "way up"? A malicious user who can execute SQL can DOS
the database trivially. Doing the (non-trivial) infrastructure work to
fix that is probably a good idea, but I don't see that not installing
pl/pgsql by default is going to make much of a difference.

> 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

That would be one solution. Another would be to only install pl/pgsql by
default when shared libraries are available. While that would mean
pl/pgsql wouldn't be available on platforms without shared libraries,
that's no worse than the status quo.

> 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 we effectively just ran the CREATE FUNCTION and CREATE LANGUAGE
commands for pl/pgsql in a late stage of initdb, the language and its
associated functions wouldn't be builtin. The DBA would then be able to
drop pl/pgsql via droplang (which might need to be hacked up a bit to do
this).

-Neil

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Hansen 2005-05-07 04:44:58 Re: Patch for collation using ICU
Previous Message John Hansen 2005-05-07 04:21:48 Re: Patch for collation using ICU