Andrew Dunstan <andrew@dunslane.net> writes:
> Thanks. The only significant problem I saw mentioned other than the
> rather ephemeral security issues was the one regarding statically linked
> postgres.
Nothing like establishing one's point by carefully ignoring all the
nontrivial problems.
I think the real $64 issue is that plpgsql provides a usable procedural
programming language on the server side, and is therefore a springboard
to enable users doing things the DBA might not like --- the example of
using server-side resources to do password cracking is one. Another
example is that it'd enable use of covert communication channels such as
CPU usage, which'd be a heck of a lot harder to do with only SQL access.
Thus it is entirely reasonable for a DBA to see plpgsql as exacerbating
any security issues that might exist, *whether or not plpgsql itself has
any holes*. Indeed, I'd say a DBA who does not realize that that's a
risk is a fool.
What was that again about "let's be secure by default"? This proposal
is certainly not moving in that direction.
Still and all, I will hold still for having it be installed by default
as long as there is a simple way for the DBA to change that default
--- let's say, roughly as simple as it is now for the DBA to make it the
default if he wishes (ie "create language plpgsql" in template1) and
revoke that again if he changes his mind ("drop language plpgsql" in
template1). initdb-time switches are not an adequate answer, not least
because most packagers don't make it easy to control them.
BTW, why all the pressure for this when we've already made it possible
for database owners to create the language by default?
regards, tom lane