Are there are more possibilities for some bug in the plpgsql engine to allow an
exploit: actually changing the stack through a buffer overflow, or a bug in an
intrinsic function, or allowing an injection that crosses some privilege
boundary, via someone else's EXECUTE?
It's a lot easier to verify the few places where straight SQL can interact with
the outside world (NOTIFY, COPY, and trojan .so's come to mind). It is harder
for someone to find an unexpected combined-effect exploit, since there's not
much you can combine.
Perhaps somebody in the core team has reservations about possible points of
error to certify in plpgsql: is every possible weird array-overflow case
covered? Further, can some innocuous side-effects in execution (INOUT
parameters; function ownership; schema settings) combine to create a hole?
There's just that much more to worry about.
As they say, in theory, theory and practice are the same.
In practice, they differ :0)
I can understand someone being cautious about making guarantees (or even risk
estimates) about plpgsql versus
the core engine. And so, just like not INITIALLY letting the server listen on
all TCP sockets, it's modest conservatism to let the default be a bit restricted.
--
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.
