De acordo com os documentos:
PL/Python está disponível apenas como uma linguagem "não confiável", o que significa que não oferece nenhuma maneira de restringir o que os usuários podem fazer nela e, portanto, é chamada de plpythonu. Uma variante confiável do plpython pode se tornar disponível no futuro se um mecanismo de execução seguro for desenvolvido em Python.
Por que exatamente é difícil desenvolver um mecanismo de execução seguro para Python, mas não para outras linguagens como Perl?
Tem a ver com o modelo de objeto do Python - sempre há uma maneira de obter uma referência a objetos que podem ser inseguros. Consulte a documentação do módulo rexec e o capítulo de execução restrita dos documentos para obter algumas informações sobre os problemas, bem como:
As limitações não têm nada a ver com o PostgreSQL em si, elas são inerentes à implementação do interpretador CPython ou possivelmente até mesmo à própria linguagem Python.
Algumas outras linguagens verificaram tempos de execução, como Perl, Java, JavaScript e Lua. A maioria deles enfrentou uma série de problemas de segurança, pois esses ambientes de execução confinados são muito difíceis de proteger contra todas as possíveis explorações de jailbreak.
Não há realmente nada que impeça o PostgreSQL de adicionar um interpretador Python semiconfiável, já que o rexec é "bom o suficiente" para muitos propósitos. No entanto, o PostgreSQL não tende a se interessar por apenas-quase-bom-o-suficiente-talvez. Ele provavelmente só seria aceito se marcado como somente superusuário, mas você sempre poderia conceder acesso a ele para usuários específicos. Seria melhor do que Python não confiável.
Pessoalmente, acho que PL/V8 ou similar é o futuro aqui e gostaria de vê-lo avançar para ser suportado no núcleo.
Também explorei vagamente a ideia de um Mono confiável que pode carregar assemblies "seguros" escritos em C#, VB.NET, IronPython ou qualquer outro, mas não consegui fazer muito sobre esse assunto.