Re: plpgsql by default

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.