Paso lentamente de MSSQL a PostgreSQL.Cómo editar el procedimiento almacenado de PostgreSQL?
En MSSQL podría llamar la edición del procedimiento o función ya guardado, y el shell de administración (SQL Server Management Studio) me mostró el texto del procedimiento, así que no tuve que almacenar su código fuente en algún archivo de texto.
¿Cómo hacer lo mismo con PostgreSQL de la manera más conveniente? Estoy usando pgAdmin III.
phpPgAdmin le permitirá editar sus procedimientos almacenados y editarlos dentro de la interfaz. También se recomienda encarecidamente el comentario sobre su almacenamiento externo para el control de versiones.
En pgAdmin puede hacer su vida más fácil si se activa esta opción:
Archivo -> Opciones .. -> Herramienta de consulta -> [x] Copiar SQL de forma principal al diálogo SQL
Luego, lo que se muestra en el panel SQL se copiará en una ventana de la herramienta de consulta recién abierta. Por lo tanto, seleccione la función en el navegador de objetos y haga clic en el icono de la lupa en la barra de herramientas.
Tenga en cuenta un error abierto en la versión actual 1.14.2. Por defecto, public tiene el privilegio EXECUTE en las funciones. Puede REVOKE este privilegio, que solo es útil para las funciones SECURITY DEFINER. Pero este REVOKE falta en las sentencias DDL de ingeniería inversa de pgAdmin (un NULL se confunde con una ACL vacía). ¡Cuidado si eliminas y vuelves a crear esa función!
También es una forma conveniente de editar el código y probarlo.
1) Extraiga el código de una función SQL requerida de pgAdmin.
2) Coloque el código con la función en file.sql.
3) Crear un archivo de cáscara/bate en el mismo directorio con file.sql:
psql -U postgres dbname < file.sql
4) Crear un acceso directo para el archivo de la cáscara/bat en un panel rápido.
5) Edite el archivo con su editor de texto favorito y presione el atajo para actualizar la función.
En general, considero que su contribución es útil, pero en este caso específico, su sugerencia es exactamente lo que hizo * NO *: "por lo que no tuve que almacenar su código fuente en algún lugar del archivo de texto", probablemente porque piensa que este enfoque es demasiado complicado como para llamarlo "conveniente". – ChristophK
haga clic derecho en la función de árbol de objetos (en el lado izquierdo) -> Scripts -> script de creación
-o-
nueva consulta SQL Ejecutar -> código de copia de "crear o sustituir función ..."Para que
Luego editar el guión y no se olvidó de ejecutarlo
Almacenamiento del procedimiento almacenado en un archivo externo es muy recomendable de todos modos (a ser posible en un sistema de control de versiones) –
@a_horse_with_no_name:. Yo prefiero una diferente enfoque. Tengo un clúster de db de prueba para cada clúster de db productivo (con poca frecuencia copiado) donde experimento. Cuando lo considero bueno, lo implemento en el clúster de db productivo. Además de las copias de seguridad habituales, ejecuto copias de seguridad frecuentes solo de esquemas, especialmente antes/después de los cambios en el esquema. Los repositorios tradicionales son de uso limitado para los esquemas de bases de datos ya que los datos cambian constantemente y muchos cambios no se pueden (fácilmente) revertir. –
@ErwinBrandstetter: el problema con ese enfoque es que se pierde el overv iew que cambios necesita aplicar para obtener una base de datos de la versión x a la versión x + 1. Necesita un lugar centralizado donde se pueda rastrear cada cambio (e idealmente se lo asigne, por ejemplo, a un boleto de emisión). Si tiene más de un entorno (desarrollo, prueba, puesta en escena, validación, regresión, preproducción, producción) y tal vez incluso más de una versión en producción (piense en diferentes países) no veo cómo puede hacer un seguimiento de todo cambios sin un VCS. –