Procedimientos almacenados en Python para PostgreSQL

Question

todavía somos bastante nuevos en Postgres y venimos de Microsoft Sql Server.

Estamos queriendo escribir algunos procedimientos almacenados ahora. Bueno, después de luchar para obtener algo más complicado que hello world para trabajar en pl/pgsql, decidimos que es mejor si vamos a aprender un nuevo idioma, también podríamos aprender Python porque tenemos la misma consulta trabajando en ello en aproximadamente 15 minutos (nota, ninguno de nosotros conoce realmente a Python).

Tengo algunas preguntas al respecto en comparación con pl/psql.

1. ¿Está pl/Pythonu más lento que pl/pgsql?
2. ¿Hay algún tipo de referencia "buena" sobre cómo escribir buenos procedimientos almacenados para usarla? Cinco páginas cortas en la documentación de Postgres realmente no nos dicen lo suficiente.
3. ¿Qué ocurre con la preparación de consultas? ¿Debería siempre ser usado?
4. Si usamos las matrices SD y GD para una gran cantidad de planes de consulta, ¿alguna vez se llenará demasiado o tendrá un impacto negativo en el servidor? ¿Eliminará automáticamente los valores antiguos si se llena demasiado?
5. ¿Hay alguna esperanza de que se convierta en un lenguaje confiable?

Además, nuestro uso de procedimientos almacenados es extremadamente ligero. En este momento sólo tenemos 4, pero todavía estamos tratando de convertir pequeños trozos de código a través de la sintaxis específica de SQL Server (tales como variables, que no puede ser utilizado en Postgres fuera de los procedimientos almacenados)

Answer 1

1. Depende qué operaciones estás haciendo
2. Bueno, combine eso con una documentación general de Python, y eso es lo que tiene.
3. No. Nuevamente, depende de lo que esté haciendo. Si solo va a ejecutar una consulta una vez, no tiene sentido prepararla por separado.
4. Si está utilizando conexiones persistentes, podría. Pero se borran cada vez que se cierra una conexión.
5. No es probable. Sandboxing está roto en Python y AFAIK nadie está realmente interesado en solucionarlo. Escuché a alguien decir que Python-on-Parrot puede ser la forma más viable, una vez que tenemos pl/loro (que aún no lo hacemos).

Conclusión: si sus procedimientos almacenados van a hacer el trabajo de la base de datos, use pl/pgsql. Solo use pl/python si va a hacer cosas que no son de base de datos, como hablar con bibliotecas externas.