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
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 |