Andrew Dunstan <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match