En cierto reino, en cierto estado ... necesitaba agregar un disparador al modelo en
pgModeler . Qué hacer es bastante fácil. Pero para agregar una función de disparo ... También es fácil, pero tuve que lidiar un poco con los parámetros ofrecidos para el llenado / selección en la interfaz.
pgModeler es una muy buena herramienta de diseño de bases de datos que puede generar scripts sql para
PostgreSQL . Los detalles sobre esta herramienta y sus capacidades se pueden encontrar en el sitio
web oficial.
Como ejemplo, considere un modelo simplificado con una sola tabla.
Agregar una función al modelo.
Después de eso, se abrirá una ventana con varios parámetros editables con los que se creará la función. Sin embargo, algunos campos ya estarán llenos de valores predeterminados.
Consideremos estos parámetros con más detalle.
Creo que con los parámetros
Nombre ,
Esquema ,
Propietario y
Comentario todo está claro: este es el nombre de la función, el esquema de la base de datos, el propietario y el comentario para esta función, respectivamente.
Idioma es el nombre del idioma en el que se implementará la función. Para ser honesto, nunca he tenido que escribir funciones para
PostgreSQL en otra cosa que no sea
plpgsql . Por lo tanto, fue este valor para el parámetro que elegí.
Método de devolución Como en la función de activación no necesitamos devolver ni la tabla ni el conjunto de valores, dejamos
Simple .
Con los parámetros en el bloque
Tipo de datos , en general, todo también es simple. Porque Si se llama a la función en el activador, en el campo
Tipo especificamos
activador (el campo
Formato se rellenará automáticamente con el valor del
activador ). El campo
Dimensión (el único campo digital no reservado en este bloque) es necesario para indicar la dimensión de la matriz del valor devuelto. Pero como solo necesitamos un valor, no una matriz, dejamos
0 en este campo.
Con los parámetros restantes, todo no es tan obvio, al menos para mí, porque Nunca tuve que pensar en ellos durante la creación habitual de funciones en
PostgreSQL .
El tipo de función puede tomar uno de tres valores:
INMUTABLE ,
ESTABLE y
VOLATILE . A partir de la
documentación oficial de
PostgreSQL , puede descubrir que estos argumentos informan al optimizador de consultas sobre el comportamiento de la función.
- INMUTABLE significa que la función no puede modificar la base de datos y siempre devuelve el mismo resultado para ciertos valores de los argumentos.
- ESTABLE significa que la función no puede modificar la base de datos y, dentro de un escaneo de una sola tabla, siempre devuelve el mismo resultado para ciertos valores de los argumentos.
- VOLÁTIL significa que el resultado de una función puede cambiar incluso dentro de un escaneo de una sola tabla, por lo que sus llamadas no se pueden optimizar.
En consecuencia, si la función de activación requiere cambiar la base de datos, entonces
INMUTABLE no
es adecuado. Una función con el parámetro
ESTABLE no es adecuada para disparadores
DESPUÉS que desean leer líneas modificadas por el comando actual. Queda
VOLÁTIL , que no tiene los problemas anteriores. También se especificará de forma predeterminada si ninguno de los argumentos anteriores se especifica al crear la función.
La seguridad puede tomar uno de dos valores:
DEFINICIÓN DE SEGURIDAD e
INVOCADOR DE SEGURIDAD y es responsable de los derechos de qué usuario se llamará.
- DEFINER DE SEGURIDAD significa que la función se ejecutará con los derechos del usuario que la posee, es decir, el que figuraba en Propietario .
- INVOCADOR DE SEGURIDAD significa que la función se ejecutará con los derechos del usuario que la llamó.
De manera predeterminada,
se utiliza INVOCADOR DE SEGURIDAD , por lo que puede dejarlo.
El comportamiento puede tomar uno de tres valores:
ESTRICTO ,
DEVOLUCIONES NULL EN NULL INPUT y
CALLED ON NULL INPUT y muestra cómo se comportará la función si hay valores NULL entre sus argumentos.
- RETURNS NULL ON NULL INPUT o STRICT significa que la función siempre devolverá NULL si al menos uno de sus argumentos es NULL.
- CALLED ON NULL INPUT significa que la función se llamará como de costumbre, incluso si NULL está entre sus argumentos.
El valor predeterminado es
CALLED ON NULL INPUT . Por lo tanto, de la misma manera, puedes dejarlo.
Filas devueltas muestra el número de filas que el planificador esperará. El valor se especifica para funciones que devuelven conjuntos. Porque nuestra función devuelve un solo valor, dejamos
0 .
Costo de ejecución establece el costo para ejecutar esta función para el planificador. Para
plpgsql , el valor predeterminado es
100 . Por lo tanto, indicamos este valor.
Windown Func. significa que se creará una función de ventana. En nuestro caso, porque necesitamos una función de activación, no necesitamos especificar este valor (bueno, en general, escriben en la documentación misma que tiene sentido especificar este parámetro solo para funciones escritas en C).
A prueba de fugas indica que la función está sellada, es decir que no divulga información sobre sus argumentos (por ejemplo, no muestra su significado en un mensaje de error), excepto para devolver un resultado. Porque Dado que la función de activación no acepta argumentos, no es necesario especificar este parámetro.
Entonces, los parámetros de la función han terminado. El cuerpo de la función en sí se puede escribir en la misma ventana en la pestaña Definición. Procedemos a crear el disparador mismo.
Después de eso, aparecerá la ventana de creación del disparador.
Considere los parámetros que se pueden establecer en esta ventana.
Con los parámetros
Nombre ,
Alias y
Comentario, nuevamente, todo está claro: este es el nombre del activador, el alias y el comentario al activador, respectivamente.
La ejecución muestra cómo se ejecutará este activador y puede tomar uno de los siguientes valores:
ANTES ,
DESPUÉS e
INSTEAD OF , lo que significa que la función se ejecutará antes, después o en lugar del evento.
POR CADA FILA determina si el procedimiento de disparo se disparará una vez por cada fila. Si no se especifica, se establecerá el parámetro
FOR EACH STATEMENT , que determina que el procedimiento de activación se activa una vez para la instrucción SQL.
El evento determina qué eventos deben procesarse en este activador. Puede especificar múltiples eventos. Los eventos son de los siguientes tipos:
INSERT ,
UPDATE ,
DELETE y
TRUNCATE . Se producen cuando se llama al comando correspondiente con la misma instrucción SQL.
La restricción indica que se creará un activador de restricción. Los desencadenantes de restricciones se utilizan para generar excepciones cuando se violan las restricciones. Puede leer más sobre ellos en la
documentación oficial.
Para un activador de restricción, puede especificar
Diferible , que determina el tiempo de activación. Este parámetro puede tomar uno de los siguientes valores:
INICIALMENTE INMEDIATO o
INICIALMENTE DIFERIDO .
- INICIALMENTE INMEDIATO significa que el disparador se disparará después de cada declaración.
- INICIALMENTE DIFERIDO significa que el disparador se disparará solo al final de la transacción.
Consulte Tabla es el nombre de la tabla a la que hace referencia la restricción. Se usa para restricciones de clave externa y se permite solo para desencadenantes de restricción.
La condición es una condición que determina si se ejecutará la función de disparo. Para los disparadores
FOR EACH ROW en este campo, puede acceder a los valores antiguos y nuevos a través de
OLD y
NEW, respectivamente (es decir, lo mismo que en el cuerpo de la función de disparo).
Argumentos : una lista de argumentos que se pasarán a la función de activación cuando se active la activación. Las constantes de cadena se pasan como argumentos a la función.
Columnas : solo se pueden especificar para eventos de
ACTUALIZACIÓN . El activador solo funcionará si al menos una de las columnas especificadas está en la lista de columnas especificadas en
ACTUALIZAR .
Conclusión
Eso, en general, es todo. Espero que esto haya sido interesante y sea útil para alguien.
Al escribir este artículo, se utilizó pgModeler versión 0.9.2-alpha,
construida bajo Windows 7 x64. Cuando se usan versiones anteriores / nuevas de pgModeler, son posibles pequeñas diferencias en la interfaz.
El modelo utilizado en el artículo se puede descargar
aquí .