A partir da minha experiência, o pl/java tem alguns problemas importantes:
- É difícil instalá-lo em um servidor postgresql. Mesmo se você encontrar uma compilação binária para sua versão do postgresql (o que também é difícil) - ela precisa de alguns malabarismos de configuração e caminho de biblioteca.
- A primeira chamada para o procedimento armazenado Java resultará em um novo processo JVM. Os processos da JVM têm escopo de conexão e exigem alguma quantidade de memória para heap java, portanto, se você usar o pool de conexões, terá de 10 a 20 JVMs iniciadas e não utilizadas na maior parte do tempo, consumindo a RAM do servidor
- pl/java pode se comunicar com o banco de dados postgresql usando um driver JDBC que emula o uso comum de JDBC, mas tem alguns problemas de implementação que podem surpreendê-lo. Especialmente se você quiser usar cursores JDBC ou outras coisas não tão comuns.
- pl/java logging é bastante especial - é por causa da implementação de manipulação de erros internos do postgresql. Por exemplo - se você registrar algo com java logging api no nível de log ERROR - ele encerrará sua conexão com o servidor.
- pl/java tem um desempenho de processamento de dados muito bom em comparação com a lógica java baseada em servidor de aplicativos, mas é totalmente inescalável - os procedimentos pl/java são totalmente single-threaded - o postgresql proíbe procedimentos multi-thread
- Se você usar o driver JDBC interno e sua instrução SQL contiver erros - você acabará com uma mensagem de erro enigmática no log do postgresql - totalmente sem relação com o problema real.
Como resultado - você pode usar procedimentos pl/java com algum sucesso, mas precisa fazê-lo com muito cuidado e provavelmente precisa pensar em melhorar o design do seu aplicativo.