Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Pensado para quienes deben dominar PL/pgSQL en su día a día
Desarrolladores backend
Este curso encaja con desarrolladores que trabajan con aplicaciones conectadas a PostgreSQL y necesitan comprender mejor qué lógica puede vivir dentro de la base de datos. Aprenderán a diseñar funciones, procedimientos, triggers y APIs internas sin convertir la base en una caja negra ni duplicar reglas entre backend, scripts y procesos batch.
DBAs y administradores PostgreSQL
Los perfiles de administración podrán reforzar su capacidad para revisar código PL/pgSQL, diagnosticar errores, analizar bloqueos, optimizar funciones, controlar permisos, auditar cambios y acompañar a equipos de desarrollo con criterios sólidos de rendimiento, seguridad y operación.
Data Engineers y Analytics Engineers
Los equipos de datos podrán usar PL/pgSQL para automatizar cargas, validar reglas, transformar información, procesar staging tables, controlar errores y construir procesos reproducibles. El curso les ayuda a escribir lógica cercana al dato sin caer en soluciones lentas, frágiles o difíciles de mantener.
Arquitectos de software y datos
Los perfiles de arquitectura podrán decidir qué responsabilidades conviene ubicar en PL/pgSQL, cuáles deben mantenerse en servicios o pipelines y cómo gobernar la frontera entre base de datos, aplicación, integración y consumo analítico.
Equipos de mantenimiento y modernización
Los equipos que heredan bases PostgreSQL con funciones antiguas, triggers poco documentados, scripts manuales o lógica procedural crítica aprenderán a diagnosticar, probar, refactorizar y documentar sin romper comportamiento productivo.
QA técnico y responsables de calidad
Los perfiles de calidad podrán validar funciones, procedimientos, triggers, permisos, errores y procesos de datos con escenarios repetibles. La formación les permite conectar pruebas de base de datos con CI/CD, control de cambios y criterios de aceptación técnica.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en PL/pgSQL
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Parte desde las preguntas fundamentales de PL/pgSQL, pero avanza hacia un nivel profesional. Es recomendable conocer SQL, tablas, joins, transacciones y conceptos básicos de PostgreSQL para aprovecharlo bien.
Sí. PL/pgSQL forma parte del ecosistema oficial de PostgreSQL para desarrollar funciones, procedimientos, triggers y lógica procedural dentro de la base de datos. La documentación actual de PostgreSQL mantiene un capítulo específico dedicado a PL/pgSQL.
Sí. El curso se plantea sobre PostgreSQL 18 o sobre la versión corporativa soportada por la empresa. PostgreSQL publica documentación vigente para la versión actual 18 y mantiene versiones soportadas anteriores.
Sí. Se trabajan funciones, procedimientos, parámetros, tipos de retorno, contratos, errores, transacciones, permisos, testing, documentación y consumo desde aplicaciones o procesos de datos.
Sí. El curso incluye trigger functions, variables especiales, triggers por fila y sentencia, auditoría, validaciones, riesgos, rendimiento, pruebas y alternativas. PostgreSQL documenta PL/pgSQL como lenguaje válido para definir trigger functions.
Sí. Se trabajan `EXPLAIN`, `EXPLAIN ANALYZE`, índices, SQL embebido, cursores, operaciones set-based, locks, funciones llamadas desde consultas, materialized views y procesos batch.
Sí. Se profundiza en roles, grants, ownership, `SECURITY DEFINER`, `SECURITY INVOKER`, `search_path`, SQL dinámico seguro, protección de datos sensibles y pruebas de acceso.
Sí. JSONB se incluye como parte importante del curso para contratos de entrada, APIs, eventos, validación de payloads, normalización, consultas, índices y procesos de integración.
Sí. Se trabaja versionado en Git, migraciones, herramientas como Flyway o Liquibase si la empresa las usa, pruebas automatizadas, rollback, revisión de permisos y pipelines de validación.
Sí. El curso contempla PostgreSQL self-managed y servicios gestionados como Amazon RDS, Aurora, Azure Database for PostgreSQL o Cloud SQL, teniendo en cuenta permisos, extensiones y limitaciones operativas.
No. Es una formación corporativa práctica para desarrollo, DBA, datos y arquitectura. Puede reforzar conocimientos útiles de PostgreSQL, pero no sustituye una preparación oficial de certificación.
Sí. Al tratarse de una formación corporativa en bases de datos, PostgreSQL, desarrollo PL/pgSQL, seguridad, rendimiento, datos y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Parte desde las preguntas fundamentales de PL/pgSQL, pero avanza hacia un nivel profesional. Es recomendable conocer SQL, tablas, joins, transacciones y conceptos básicos de PostgreSQL para aprovecharlo bien.
Sí. PL/pgSQL forma parte del ecosistema oficial de PostgreSQL para desarrollar funciones, procedimientos, triggers y lógica procedural dentro de la base de datos. La documentación actual de PostgreSQL mantiene un capítulo específico dedicado a PL/pgSQL.
Sí. El curso se plantea sobre PostgreSQL 18 o sobre la versión corporativa soportada por la empresa. PostgreSQL publica documentación vigente para la versión actual 18 y mantiene versiones soportadas anteriores.
Sí. Se trabajan funciones, procedimientos, parámetros, tipos de retorno, contratos, errores, transacciones, permisos, testing, documentación y consumo desde aplicaciones o procesos de datos.
Sí. El curso incluye trigger functions, variables especiales, triggers por fila y sentencia, auditoría, validaciones, riesgos, rendimiento, pruebas y alternativas. PostgreSQL documenta PL/pgSQL como lenguaje válido para definir trigger functions.
Sí. Se trabajan `EXPLAIN`, `EXPLAIN ANALYZE`, índices, SQL embebido, cursores, operaciones set-based, locks, funciones llamadas desde consultas, materialized views y procesos batch.
Sí. Se profundiza en roles, grants, ownership, `SECURITY DEFINER`, `SECURITY INVOKER`, `search_path`, SQL dinámico seguro, protección de datos sensibles y pruebas de acceso.
Sí. JSONB se incluye como parte importante del curso para contratos de entrada, APIs, eventos, validación de payloads, normalización, consultas, índices y procesos de integración.
Sí. Se trabaja versionado en Git, migraciones, herramientas como Flyway o Liquibase si la empresa las usa, pruebas automatizadas, rollback, revisión de permisos y pipelines de validación.
Sí. El curso contempla PostgreSQL self-managed y servicios gestionados como Amazon RDS, Aurora, Azure Database for PostgreSQL o Cloud SQL, teniendo en cuenta permisos, extensiones y limitaciones operativas.
No. Es una formación corporativa práctica para desarrollo, DBA, datos y arquitectura. Puede reforzar conocimientos útiles de PostgreSQL, pero no sustituye una preparación oficial de certificación.
Sí. Al tratarse de una formación corporativa en bases de datos, PostgreSQL, desarrollo PL/pgSQL, seguridad, rendimiento, datos y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
Tema 2: Entorno de trabajo PostgreSQL para desarrollo PL/pgSQL
Preparar un entorno PostgreSQL de laboratorio en local, Docker, servidor corporativo o servicio cloud, separando claramente prácticas y producción.
Configurar herramientas como `psql`, pgAdmin, DBeaver, DataGrip o clientes corporativos para ejecutar scripts, revisar errores y validar resultados.
Crear una base de datos de laboratorio con esquemas, tablas, constraints, índices, datos sintéticos y usuarios diferenciados.
Organizar scripts en repositorio separando DDL, DML, funciones, procedimientos, triggers, pruebas, migraciones y rollback.
Configurar permisos mínimos para que el usuario de laboratorio pueda crear objetos sin recibir privilegios administrativos innecesarios.
Usar `psql` para ejecutar scripts reproducibles, controlar variables, mostrar mensajes y validar despliegues desde terminal.
Revisar errores de compilación y ejecución de funciones mediante mensajes del cliente, `RAISE`, logs y vistas del catálogo.
Diferenciar ejecución interactiva, scripts versionados, migraciones automatizadas y cambios manuales no permitidos.
Crear convenciones de nombres para esquemas, funciones, procedimientos, triggers, tipos, variables y scripts de despliegue.
Documentar la preparación del entorno para que cualquier alumno pueda restaurar el laboratorio y repetir las prácticas sin dependencia manual.
Tema 3: Fundamentos del lenguaje PL/pgSQL
Crear bloques PL/pgSQL con secciones de declaración, cuerpo ejecutable y manejo de errores, entendiendo qué responsabilidad tiene cada parte.
Declarar variables, constantes, tipos derivados y registros con nombres que expresen intención funcional y no solo detalle técnico.
Usar asignaciones, expresiones, operadores, llamadas a funciones y resultados de consultas dentro de rutinas PL/pgSQL.
Comprender el alcance de variables, bloques anidados y nombres que pueden entrar en conflicto con columnas o parámetros.
Aplicar comentarios útiles para explicar reglas de negocio, decisiones no evidentes y restricciones operativas.
Usar `DO` blocks para pruebas puntuales, operaciones administrativas controladas o validación de lógica antes de crear funciones persistentes.
Diferenciar código experimental, código de despliegue, código productivo y scripts de soporte.
Evitar rutinas largas desde el principio, dividiendo responsabilidades en funciones pequeñas y contratos claros.
Probar fragmentos de lógica con datos sintéticos antes de incorporarlos a procesos críticos.
Construir un primer bloque PL/pgSQL que declare variables, ejecute una consulta, tome una decisión y registre un mensaje controlado.
Tema 4: Tipos de datos, variables y registros
Usar tipos escalares de PostgreSQL como `integer`, `numeric`, `text`, `boolean`, `date`, `timestamp`, `uuid`, `jsonb` y tipos propios del dominio.
Declarar variables basadas en columnas mediante `%TYPE` para reducir errores cuando cambia el tipo de una columna relevante.
Usar registros con `%ROWTYPE` o `record` cuando una rutina necesita trabajar con filas completas o resultados dinámicos.
Diferenciar tipos SQL persistentes, tipos compuestos, dominios y variables internas de PL/pgSQL.
Gestionar valores nulos con criterio, evitando comparaciones incorrectas y resultados inesperados en condiciones.
Controlar conversiones explícitas entre texto, fechas, números, UUIDs y JSON para evitar errores dependientes de formato o sesión.
Usar dominios y tipos compuestos cuando aportan semántica, validación o reutilización en el modelo de datos.
Evitar variables genéricas como `v_texto` o `v_dato` cuando el valor representa un concepto de negocio concreto.
Probar rutinas con valores nulos, extremos, tipos incorrectos y datos fuera de catálogo.
Crear una rutina que valida tipos, normaliza entradas y devuelve errores claros cuando recibe datos no aceptables.
Tema 5: Control de flujo: IF, CASE, LOOP y estructuras de decisión
Aplicar `IF`, `ELSIF` y `ELSE` para representar decisiones de negocio sin crear estructuras anidadas imposibles de mantener.
Usar `CASE` cuando la lógica depende de estados, códigos, categorías o reglas con varias salidas posibles.
Diseñar condiciones legibles que separen validación previa, reglas de negocio, excepciones funcionales y caminos alternativos.
Evitar condicionales extensos reemplazándolos por funciones auxiliares, tablas de configuración o reglas más declarativas cuando procede.
Usar `LOOP`, `WHILE`, `FOR` y `FOREACH` con criterio, entendiendo cuándo una iteración procedural aporta valor real.
Evitar bucles innecesarios cuando una operación set-based con SQL resuelve el problema de forma más simple y eficiente.
Controlar salidas de bucle, contadores, límites y condiciones de parada para evitar ejecuciones infinitas o procesos bloqueados.
Documentar reglas críticas cuando afectan a facturación, estados, permisos, cierres, validaciones o flujos regulatorios.
Probar cada rama con datos reales simulados, incluyendo casos límite, nulos y estados no esperados.
Construir un flujo de decisión empresarial con validación, clasificación, tratamiento de excepciones y resultado verificable.
Tema 6: SQL embebido en PL/pgSQL
Ejecutar consultas `SELECT INTO` gestionando correctamente ausencia de filas, múltiples filas y resultados esperados.
Usar `INSERT`, `UPDATE`, `DELETE` y `MERGE` desde PL/pgSQL con control de filas afectadas y validación de impacto.
Integrar variables de PL/pgSQL en sentencias SQL sin introducir ambigüedad entre nombres de columnas y nombres de variables.
Usar `FOUND`, `GET DIAGNOSTICS` y recuentos de filas para validar efectos de operaciones DML.
Diseñar operaciones idempotentes cuando una función o procedimiento puede reintentarse por fallo de integración o proceso batch.
Evitar consultas dentro de bucles cuando pueden resolverse con joins, CTEs, agregaciones o DML por conjuntos.
Crear rutinas que leen datos, aplican reglas y modifican registros con garantías de consistencia.
Controlar errores por constraints, claves duplicadas, referencias inexistentes o conversiones fallidas.
Revisar impacto de cada sentencia SQL embebida mediante `EXPLAIN`, estadísticas y pruebas con volumen representativo.
Construir una función que combina consulta, validación, actualización y respuesta estructurada para una operación de negocio.
Tema 7: Funciones PL/pgSQL: diseño, parámetros y contratos
Crear funciones con `CREATE FUNCTION`, parámetros tipados, valor de retorno claro y finalidad funcional bien definida.
Diseñar funciones pequeñas, cohesivas y reutilizables, evitando convertir cada función en un proceso completo de aplicación.
Usar parámetros `IN`, valores por defecto y nombres expresivos para mejorar legibilidad y mantenimiento.
Definir retornos escalares, compuestos, `TABLE`, `SETOF`, `record` o JSON según el contrato que necesita el consumidor.
Diferenciar funciones pensadas para consultas SQL, funciones internas de apoyo y funciones usadas como API controlada.
Evitar funciones con efectos secundarios inesperados cuando se usan dentro de consultas, filtros o vistas.
Marcar correctamente volatilidad con `IMMUTABLE`, `STABLE` o `VOLATILE` solo cuando se comprende su impacto.
Documentar cada función con propósito, parámetros, retorno, errores esperados, permisos y ejemplos de uso.
Probar funciones con entradas válidas, inválidas, nulas, límites y escenarios de permisos.
Construir una biblioteca de funciones PL/pgSQL con contratos claros, pruebas y documentación mínima.
Tema 8: Procedimientos almacenados y control transaccional
Crear procedimientos con `CREATE PROCEDURE` cuando se necesita ejecutar operaciones que no encajan bien como funciones de consulta.
Diferenciar funciones y procedimientos en PostgreSQL, especialmente por intención, forma de invocación y control transaccional.
Diseñar procedimientos para procesos batch, mantenimiento, cargas, cierres, consolidaciones o tareas administrativas controladas.
Gestionar parámetros de entrada y salida de forma predecible, evitando interfaces que ocultan demasiados efectos secundarios.
Controlar transacciones con criterio, entendiendo cuándo el procedimiento debe formar parte de una transacción superior.
Evitar commits o rollbacks improvisados en rutinas reutilizables si pueden romper flujos de aplicación o pipelines.
Registrar progreso y errores en procedimientos largos sin convertir el log en una fuente de datos sensibles.
Crear procedimientos reejecutables que soportan reintentos, cancelaciones y recuperación parcial.
Documentar cuándo un procedimiento puede ejecutarse manualmente, desde job, desde aplicación o desde pipeline.
Construir un procedimiento empresarial que procesa datos por lote, registra métricas y permite validación posterior.
Tema 9: Cursores, procesamiento fila a fila y alternativas set-based
Usar cursores explícitos cuando se requiere controlar lectura incremental, procesamiento complejo o interacción con lotes grandes.
Diferenciar `FOR record IN query`, cursores declarados, cursores con parámetros y cursores devueltos como `refcursor`.
Evitar cursores por costumbre cuando una única sentencia SQL puede resolver la operación con mejor rendimiento.
Diseñar procesamiento por lotes cuando el volumen exige controlar memoria, locks, tiempos de ejecución y recuperación.
Usar cursores para integraciones, transformaciones complejas o flujos donde cada fila tiene tratamiento diferenciado real.
Controlar cierre de cursores, errores intermedios y estado de ejecución para no dejar procesos en situación incierta.
Medir rendimiento frente a alternativas con CTEs, `INSERT INTO SELECT`, `UPDATE FROM`, `MERGE` o funciones de ventana.
Registrar progreso en procesos largos sin hacer commits arbitrarios que rompen atomicidad.
Probar cursores con pocos datos, muchos datos, errores por fila y cancelación controlada.
Refactorizar un proceso fila a fila hacia una solución set-based cuando el análisis demuestra mejora real.
Tema 10: Excepciones, errores y mensajes controlados
Usar bloques `EXCEPTION` para capturar errores esperados y convertirlos en respuestas comprensibles para el proceso consumidor.
Diferenciar errores de negocio, errores de validación, errores técnicos, errores de concurrencia y errores de permisos.
Usar `RAISE NOTICE`, `RAISE WARNING` y `RAISE EXCEPTION` con criterio, evitando ruido excesivo y mensajes inseguros.
Propagar errores críticos en lugar de ocultarlos con handlers genéricos que dejan datos inconsistentes.
Capturar información de diagnóstico con `GET STACKED DIAGNOSTICS` cuando se necesita registrar causa, detalle y contexto.
Crear códigos y mensajes funcionales estables cuando las aplicaciones consumidoras necesitan reaccionar a errores concretos.
Evitar incluir datos personales, secretos, tokens o payloads sensibles en mensajes de error o logs.
Diseñar una tabla de errores para procesos batch que permita revisar filas rechazadas, motivo y acción correctiva.
Probar errores igual que caminos de éxito, incluyendo constraints, duplicados, nulos, permisos y datos inválidos.
Construir un patrón de manejo de errores PL/pgSQL con logging, diagnóstico, relanzamiento y mensajes seguros.
Tema 11: Transacciones, bloqueos y consistencia de datos
Comprender cómo PL/pgSQL participa en transacciones PostgreSQL y cómo afecta a funciones, procedimientos, triggers y llamadas desde aplicación.
Diseñar rutinas que mantienen consistencia sin bloquear más filas ni más tiempo del necesario.
Usar `SELECT ... FOR UPDATE` cuando una operación requiere bloquear filas antes de modificarlas.
Gestionar concurrencia en procesos de reserva, asignación, colas, cambios de estado y operaciones sensibles.
Diferenciar errores de serialización, deadlocks, esperas por locks y conflictos lógicos de negocio.
Crear estrategias de reintento controlado cuando una operación puede fallar por concurrencia transitoria.
Evitar transacciones largas que mezclan consultas, llamadas externas, decisiones de usuario y DML crítico.
Analizar locks mediante vistas del sistema, logs, sesiones y pruebas con conexiones paralelas.
Documentar qué rutinas esperan ser llamadas dentro de una transacción externa y cuáles controlan su propia operación.
Construir un laboratorio de concurrencia con dos sesiones, bloqueos, rollback, reintento y validación de consistencia.
Tema 12: Triggers y trigger functions
Crear trigger functions en PL/pgSQL para reaccionar ante cambios en tablas o eventos de base de datos cuando existe una razón clara.
Diferenciar triggers `BEFORE`, `AFTER` e `INSTEAD OF`, así como triggers por fila y por sentencia.
Usar variables especiales como `NEW`, `OLD` y variables `TG_*` para entender contexto, operación y objeto que dispara el trigger.
Aplicar triggers para auditoría, validaciones localizadas, mantenimiento de columnas derivadas o integración controlada.
Evitar triggers con lógica de negocio extensa que sorprende a aplicaciones, procesos batch y equipos de soporte.
Controlar efectos secundarios, recursividad, orden de ejecución, rendimiento y dificultad de depuración.
Documentar triggers sobre tablas críticas para que ningún cambio desconozca efectos automáticos al insertar, actualizar o borrar.
Probar triggers con operaciones de una fila, operaciones masivas, errores, rollback y concurrencia.
Evaluar alternativas como constraints, generated columns, procedimientos explícitos, reglas de aplicación o jobs.
Refactorizar un trigger opaco hacia una solución más mantenible, probada y documentada.
Tema 13: Constraints, dominios y validación declarativa frente a procedural
Usar constraints como primera línea de defensa para integridad: claves primarias, claves externas, `UNIQUE`, `CHECK` y `NOT NULL`.
Crear dominios cuando un tipo de dato necesita una regla común reutilizable en varias columnas o tablas.
Decidir cuándo una validación debe ser declarativa y cuándo necesita PL/pgSQL por depender de lógica más compleja.
Evitar implementar en funciones reglas que PostgreSQL puede garantizar mejor mediante constraints.
Diseñar mensajes y pruebas que permitan detectar claramente qué regla de integridad ha fallado.
Revisar impacto de constraints en cargas masivas, migraciones, procesos batch y datos legacy.
Combinar constraints, funciones y triggers sin duplicar validaciones ni generar resultados contradictorios.
Documentar reglas de integridad para que desarrollo y negocio comprendan qué protege la base de datos.
Probar datos inválidos, duplicados, referencias rotas y estados prohibidos antes de publicar cambios.
Construir un modelo de validación donde constraints y PL/pgSQL colaboran sin solaparse innecesariamente.
Tema 14: SQL dinámico seguro con EXECUTE
Usar `EXECUTE` en PL/pgSQL cuando la estructura de la sentencia debe construirse dinámicamente en tiempo de ejecución.
Diferenciar SQL dinámico justificado de SQL dinámico usado por comodidad y con mayor riesgo de seguridad.
Construir sentencias dinámicas con `format()`, `%I`, `%L` y parámetros `USING` para reducir riesgos de inyección.
Validar nombres de tablas, columnas, esquemas y operaciones mediante listas permitidas antes de componer SQL.
Evitar concatenar valores de usuario, filtros o fragmentos de consulta sin validación estricta.
Diseñar utilidades de administración, auditoría o mantenimiento que trabajan con objetos variables de forma segura.
Registrar sentencias dinámicas en modo diagnóstico sin exponer datos sensibles ni credenciales.
Probar SQL dinámico con entradas válidas, inválidas, maliciosas, nulas y casos límite.
Revisar permisos y `SECURITY DEFINER` con especial cuidado cuando se combinan con SQL dinámico.
Construir una función de mantenimiento con SQL dinámico seguro, validación de identificadores y control de errores.
Tema 15: JSON, JSONB y lógica procedural
Usar `json` y `jsonb` para manejar payloads semiestructurados recibidos desde APIs, eventos, integraciones o procesos externos.
Extraer, validar y transformar propiedades JSON dentro de funciones PL/pgSQL sin perder control de tipos y errores.
Diseñar rutinas que reciben JSON como contrato de entrada, validan estructura y publican datos en tablas relacionales.
Evitar guardar todo en JSONB cuando el dato necesita joins, constraints, índices, trazabilidad o reglas relacionales fuertes.
Crear errores claros para payloads incompletos, propiedades ausentes, tipos incorrectos o formatos no permitidos.
Usar JSONB para metadatos flexibles, eventos, configuraciones o datos cambiantes cuando el caso lo justifica.
Indexar y consultar JSONB con criterio cuando ciertos campos se filtran o consultan de forma recurrente.
Documentar contratos JSON con versión, campos obligatorios, campos opcionales, compatibilidad y reglas de evolución.
Probar rutinas con documentos válidos, inválidos, arrays, objetos anidados, valores nulos y campos inesperados.
Construir una función PL/pgSQL que ingiere JSONB, valida reglas, registra errores y normaliza datos en tablas.
Tema 16: Arrays, rangos y tipos avanzados de PostgreSQL
Usar arrays cuando un conjunto de valores pertenece a una operación concreta, evitando reemplazar relaciones normalizadas sin motivo.
Iterar arrays con `FOREACH` y funciones auxiliares cuando se necesita lógica procedural sobre listas controladas.
Usar tipos de rango para representar intervalos de fechas, importes, numeraciones o periodos de vigencia.
Diseñar validaciones de solapamiento, disponibilidad, reservas, vigencias o planificación usando rangos y operadores nativos.
Crear tipos compuestos cuando una rutina necesita devolver o manipular estructuras de negocio más expresivas.
Evitar estructuras avanzadas si el equipo no podrá consultarlas, indexarlas, probarlas o mantenerlas correctamente.
Integrar arrays, rangos y tipos compuestos con funciones, procedimientos, vistas y contratos de aplicación.
Revisar índices adecuados para consultas con rangos, arrays o datos complejos.
Probar casos límite: arrays vacíos, rangos abiertos, rangos solapados, valores nulos y estructuras mal formadas.
Construir una rutina de planificación que valida disponibilidad usando rangos, arrays y errores controlados.
Tema 17: Funciones set-returning, RETURNS TABLE y APIs de lectura
Crear funciones que devuelven conjuntos de filas mediante `RETURNS TABLE`, `SETOF` o tipos compuestos.
Diseñar APIs de lectura en base de datos para exponer datos filtrados, calculados o protegidos sin dar acceso directo a tablas internas.
Controlar paginación, filtros, ordenación, permisos y estabilidad del contrato en funciones de lectura.
Evitar funciones set-returning que ocultan consultas lentas, joins excesivos o lógica difícil de optimizar.
Documentar columnas devueltas, significado funcional, consumidores previstos y cambios incompatibles.
Comparar funciones de lectura con vistas, materialized views, consultas directas o endpoints de aplicación.
Aplicar `RETURN QUERY` para expresar consultas complejas de forma clara dentro de PL/pgSQL.
Probar resultados con distintos filtros, usuarios, permisos, rangos de fechas y ausencia de datos.
Medir rendimiento cuando la función se usa desde aplicaciones, reporting, BI o integraciones recurrentes.
Construir una función de consulta empresarial con filtros, permisos, paginación y contrato documentado.
Tema 18: SECURITY DEFINER, search_path y seguridad de ejecución
Comprender la diferencia entre ejecución con privilegios del invocador y ejecución con privilegios del propietario de la función.
Usar `SECURITY DEFINER` solo cuando se necesita encapsular acceso controlado a objetos protegidos.
Proteger funciones `SECURITY DEFINER` fijando `search_path` y evitando que objetos maliciosos alteren la resolución de nombres.
Conceder `EXECUTE` sobre funciones o procedimientos en lugar de conceder acceso directo a tablas críticas cuando el diseño lo requiere.
Revocar permisos por defecto cuando una función sensible no debe ser ejecutable por roles amplios.
Validar entradas de funciones con privilegios elevados, especialmente si usan SQL dinámico o nombres de objetos.
Auditar ownership, grants y dependencias de funciones sensibles para detectar accesos excesivos.
Evitar que usuarios no autorizados puedan aprovechar funciones para escalar privilegios o leer datos indirectamente.
Documentar funciones de seguridad con propósito, owner, permisos, riesgos y pruebas asociadas.
Construir una API PL/pgSQL segura que permite una operación controlada sin exponer tablas internas.
Tema 19: Roles, privilegios y gobierno de acceso
Diseñar roles PostgreSQL para separar lectura, escritura, administración, ejecución de rutinas, reporting y procesos automatizados.
Conceder permisos sobre esquemas, tablas, secuencias, funciones y procedimientos con mínimos privilegios.
Evitar grants directos a usuarios personales cuando el acceso debería gestionarse por roles funcionales.
Revisar permisos efectivos para detectar privilegios heredados, grants obsoletos o accesos demasiado amplios.
Controlar `USAGE` sobre esquemas y secuencias además de permisos sobre tablas y rutinas.
Diseñar roles técnicos para aplicaciones, jobs, pipelines y usuarios interactivos con responsabilidades separadas.
Documentar matriz de permisos por entorno, esquema, objeto, rol y finalidad de negocio.
Probar escenarios de acceso permitido y denegado con usuarios de laboratorio.
Integrar permisos con despliegues versionados para que no dependan de cambios manuales posteriores.
Construir un modelo de seguridad con roles, grants, funciones controladas y pruebas de acceso.
Tema 20: Rendimiento de funciones y SQL embebido
Analizar que el rendimiento de PL/pgSQL depende en gran medida de las consultas SQL que ejecuta y del número de cambios de contexto.
Usar `EXPLAIN` y `EXPLAIN ANALYZE` para revisar planes, costes, filas estimadas, filas reales, índices y operaciones pesadas.
Detectar funciones llamadas fila a fila desde consultas grandes que generan degradaciones significativas.
Evitar bucles procedurales para operaciones que PostgreSQL puede resolver mejor mediante SQL set-based.
Revisar volatilidad, paralelismo, coste estimado y filas esperadas de funciones cuando afectan al optimizador.
Crear índices alineados con filtros, joins, ordenaciones y patrones reales de consulta usados por funciones.
Medir rendimiento con datos representativos, no solo con datasets pequeños de desarrollo.
Separar optimización de SQL, optimización de PL/pgSQL y optimización de modelo de datos para atacar la causa correcta.
Documentar mejoras de rendimiento con evidencia antes/después y riesgos asociados.
Optimizar una función lenta partiendo de métricas, plan de ejecución, refactorización y validación funcional.
Tema 21: Tablas temporales, staging y procesos por lotes
Crear tablas temporales para procesar datos intermedios, staging, validaciones o transformaciones por sesión.
Diferenciar tablas temporales, tablas staging persistentes, CTEs, vistas y estructuras en memoria según el proceso.
Diseñar cargas por etapas con recepción, validación, errores, transformación, publicación y resumen final.
Controlar índices temporales cuando un proceso intermedio necesita joins o búsquedas repetidas.
Evitar dejar tablas auxiliares persistentes sin owner, retención, limpieza o documentación.
Crear procesos reejecutables que no duplican datos ni dependen de estados manuales.
Registrar filas procesadas, rechazadas, actualizadas, duplicadas y pendientes para trazabilidad operativa.
Gestionar errores por fila frente a errores críticos que deben abortar todo el lote.
Coordinar staging con herramientas ETL, aplicaciones, colas, ficheros o integraciones externas.
Construir un proceso batch con staging, validaciones, errores, publicación y auditoría final.
Tema 22: Auditoría, logging e instrumentación
Diseñar tablas de auditoría para registrar operaciones críticas, cambios de estado, ejecuciones batch y acciones sensibles.
Separar auditoría funcional, logging técnico, trazabilidad de procesos y evidencias de cumplimiento.
Usar `RAISE` para mensajes de desarrollo y diagnóstico, sin sustituir un sistema de logging persistente cuando se necesita trazabilidad.
Registrar módulo, operación, usuario, fecha, clave de negocio, resultado, duración y número de filas afectadas.
Evitar guardar datos personales, secretos, tokens, payloads completos o información sensible innecesaria en logs.
Crear funciones auxiliares de logging reutilizables sin introducir dependencias circulares ni efectos transaccionales peligrosos.
Diseñar retención, limpieza, particionado o archivado de tablas de log para evitar crecimiento indefinido.
Relacionar logs de base de datos con logs de aplicación, IDs de correlación, jobs y procesos externos.
Crear consultas de auditoría para soporte, revisión de accesos, análisis de fallos y cumplimiento interno.
Construir un sistema de logging PL/pgSQL para procesos críticos con trazabilidad y retención controlada.
Tema 23: Extensiones y PL/pgSQL dentro del ecosistema PostgreSQL
Comprender cómo las extensiones amplían PostgreSQL y cómo pueden interactuar con funciones PL/pgSQL.
Usar extensiones aprobadas por la organización para UUIDs, criptografía, texto, auditoría, geodatos, colas o capacidades analíticas.
Evitar depender de extensiones no instaladas, no soportadas o no permitidas en entornos cloud gestionados.
Documentar extensiones requeridas por cada módulo, versión mínima, permisos y pasos de instalación.
Crear funciones PL/pgSQL que se apoyan en extensiones sin ocultar dependencias críticas.
Evaluar compatibilidad de extensiones entre PostgreSQL local, cloud gestionado, contenedores y entornos productivos.
Probar despliegues en entornos limpios para detectar dependencias no declaradas.
Revisar riesgos de seguridad y mantenimiento al introducir extensiones en bases corporativas.
Controlar actualizaciones de extensión como parte del ciclo de vida de la plataforma.
Construir un módulo que utiliza una extensión aprobada y documenta dependencia, permisos y pruebas.
Tema 24: Integración con aplicaciones, ORMs y APIs
Diseñar funciones y procedimientos consumibles desde aplicaciones .NET, Java, Python, Node.js u otros backends corporativos.
Decidir cuándo una aplicación debe llamar a una función PL/pgSQL y cuándo debe usar SQL parametrizado, ORM o servicio intermedio.
Evitar acoplar aplicaciones a detalles internos de tablas, triggers o rutinas auxiliares no pensadas como contrato público.
Diseñar contratos de entrada y salida claros: parámetros, tipos, errores, resultados, permisos y transacciones.
Gestionar llamadas desde ORMs como Entity Framework, Hibernate, SQLAlchemy o herramientas equivalentes sin romper mantenibilidad.
Controlar transacciones cuando aplicación y PL/pgSQL participan en la misma operación funcional.
Devolver resultados estructurados mediante tablas, tipos compuestos o JSON según necesidades del consumidor.
Probar integraciones con usuarios técnicos, permisos reales de ejecución, errores esperados y datos de laboratorio.
Documentar funciones públicas como APIs internas de datos, con ejemplos de llamada y condiciones de uso.
Construir una integración de ejemplo donde una aplicación consume una función PL/pgSQL como operación controlada.
Tema 25: PL/pgSQL para ETL, ELT y pipelines de datos
Usar PL/pgSQL para validar, transformar y publicar datos dentro de procesos ELT cuando el dato ya reside en PostgreSQL.
Diseñar pipelines por etapas con staging, validación, normalización, enriquecimiento, publicación y auditoría.
Integrar funciones y procedimientos con orquestadores, jobs, Airflow, dbt, scripts, cron o herramientas corporativas.
Evitar concentrar demasiada lógica procedural dentro de PostgreSQL cuando el pipeline necesita escalado externo o procesamiento distribuido.
Crear controles de calidad: duplicados, nulos, rangos, referencias, formatos, reglas de negocio y conciliaciones.
Registrar métricas de pipeline: duración, filas recibidas, aceptadas, rechazadas, modificadas y pendientes.
Diseñar procesos reejecutables con claves de lote, estados, checkpoints y recuperación ante fallo.
Usar transacciones y locks con cuidado para no bloquear cargas o consumos analíticos.
Documentar dependencias entre tablas, procesos, vistas, funciones y consumidores.
Construir un pipeline ELT con PL/pgSQL, staging, validación, errores y publicación controlada.
Tema 26: Materialized views, refresh y procesos de consumo
Usar materialized views cuando una consulta costosa necesita persistirse para reporting, APIs o consumo recurrente.
Diseñar funciones o procedimientos que controlan refresco, validación, bloqueo, logging y comunicación de estado.
Evaluar `REFRESH MATERIALIZED VIEW` y refresco concurrente según disponibilidad, índices y requisitos de consumo.
Evitar materializar datos sin owner, calendario, retención, criterios de frescura o consumidores claros.
Coordinar materialized views con procesos ETL, reporting, dashboards, cargas nocturnas y ventanas operativas.
Controlar permisos para que consumidores lean vistas materializadas sin acceder a tablas internas sensibles.
Medir impacto del refresco sobre recursos, locks, tiempos de respuesta y otros procesos.
Crear validaciones post-refresh para asegurar recuentos, fechas máximas, totales y consistencia básica.
Documentar dependencia entre materialized views, tablas base, funciones y procesos de actualización.
Construir un proceso de publicación analítica con materialized view, refresh controlado, logging y validación.
Tema 27: Particionamiento, mantenimiento y operaciones sobre grandes volúmenes
Comprender cuándo el particionamiento ayuda a gestionar tablas grandes por fecha, rango, lista o hash.
Diseñar funciones auxiliares para crear particiones, validar particiones futuras, mover datos o gestionar mantenimiento.
Evitar particionar por moda cuando el volumen, patrón de acceso o operación no lo justifica.
Controlar consultas sobre tablas particionadas para que aprovechen pruning y no escaneen datos innecesarios.
Gestionar mantenimiento de particiones antiguas, archivado, borrado, retención y cumplimiento.
Diseñar procesos PL/pgSQL que operan por partición para reducir locks, tiempos y consumo de recursos.
Revisar impacto de índices, constraints, triggers y claves sobre tablas particionadas.
Probar cargas, consultas y mantenimiento con volúmenes representativos antes de publicar.
Documentar estrategia de particionamiento con criterios, owner, calendario y procedimiento de emergencia.
Construir una rutina de mantenimiento para tabla particionada con creación, validación y limpieza controlada.
Tema 28: Notificaciones, LISTEN/NOTIFY y procesos reactivos
Usar `LISTEN` y `NOTIFY` para notificar eventos ligeros a aplicaciones o procesos que escuchan cambios.
Diferenciar notificaciones de PostgreSQL de colas empresariales completas, entendiendo límites de fiabilidad y persistencia.
Diseñar triggers o funciones que emiten notificaciones solo cuando el caso requiere reacción inmediata y controlada.
Evitar payloads grandes o sensibles dentro de notificaciones, usando identificadores y consulta posterior cuando procede.
Coordinar aplicaciones consumidoras para reconexión, reintento, deduplicación y tratamiento de eventos perdidos.
Documentar canales, payloads, productores, consumidores y finalidad de cada notificación.
Probar notificaciones con varias sesiones, fallos de conexión, transacciones abortadas y alto volumen.
Evaluar alternativas como colas externas, outbox pattern o CDC cuando se necesita entrega robusta.
Usar PL/pgSQL para implementar un outbox sencillo cuando la arquitectura lo requiere.
Construir un caso reactivo con trigger, notificación, payload controlado y consumidor de prueba.
Tema 29: Testing de funciones, procedimientos y triggers
Diseñar pruebas repetibles para funciones, procedimientos, triggers, permisos, errores y procesos batch.
Crear datos sintéticos que cubran escenarios de éxito, error, nulos, duplicados, límites, permisos y rollback.
Usar scripts de prueba o frameworks como pgTAP cuando la organización requiere suites automatizadas de base de datos.
Validar resultados mediante recuentos, comparaciones, tablas esperadas, errores capturados y cambios persistidos.
Probar triggers con operaciones de una fila, múltiples filas, transacciones abortadas y cargas masivas.
Evitar pruebas que dependen de datos productivos cambiantes, hora actual no controlada o ejecución en orden implícito.
Integrar pruebas PL/pgSQL en pipelines CI/CD para detectar regresiones antes de desplegar.
Separar pruebas unitarias de funciones puras, pruebas de integración sobre tablas y pruebas end-to-end de procesos completos.
Documentar escenarios cubiertos y huecos pendientes en reglas críticas de negocio.
Construir una suite de pruebas para un paquete funcional de rutinas PL/pgSQL con datos controlados y rollback.
Tema 30: Versionado, migraciones y CI/CD de código PL/pgSQL
Versionar código PL/pgSQL en Git con scripts reproducibles, orden de ejecución y trazabilidad de cambios.
Separar creación de objetos, alteraciones, datos maestros, grants, pruebas, rollback y documentación.
Usar herramientas de migración como Flyway, Liquibase, Sqitch, dbmate o soluciones corporativas equivalentes cuando estén aprobadas.
Diseñar migraciones idempotentes solo cuando aporta valor, evitando ocultar errores reales de despliegue.
Validar sintaxis, permisos, dependencias y objetos inválidos antes de aplicar cambios en entornos superiores.
Integrar pruebas, linters, revisión de formato y comprobaciones de seguridad en pipelines.
Evitar cambios manuales en producción que no quedan reflejados en repositorio ni proceso de aprobación.
Documentar releases con objetos afectados, riesgos, pruebas ejecutadas, rollback y responsables.
Coordinar cambios PL/pgSQL con cambios de aplicación, APIs, informes, jobs y consumidores externos.
Construir un pipeline de laboratorio que despliega funciones, ejecuta pruebas y valida permisos.
Tema 31: Calidad de código, estándares y revisión técnica
Definir estándares de nombres para funciones, procedimientos, triggers, variables, parámetros, tipos, errores y tablas auxiliares.
Revisar código por legibilidad, modularidad, tamaño, duplicación, manejo de errores, seguridad y rendimiento.
Evitar funciones enormes, triggers opacos, SQL dinámico inseguro, `search_path` no controlado y errores silenciados.
Crear checklist de revisión para cambios PL/pgSQL: contrato, permisos, transacción, tests, EXPLAIN, logging y rollback.
Documentar rutinas públicas con propósito, parámetros, retorno, errores, permisos y ejemplos de llamada.
Separar lógica de negocio, lógica técnica, validación, logging y transformación para facilitar mantenimiento.
Revisar impacto de cambios en consumidores, vistas, jobs, aplicaciones, pipelines y herramientas BI.
Usar formateo consistente y comentarios útiles para que el código sea revisable por más de una persona.
Establecer Definition of Done para rutinas PL/pgSQL antes de aceptar un pull request.
Construir una guía corporativa de PL/pgSQL con ejemplos correctos, anti-patrones y criterios de revisión.
Tema 32: Refactorización y modernización de PL/pgSQL legacy
Auditar código existente para detectar funciones largas, triggers invisibles, lógica duplicada, permisos excesivos y SQL lento.
Identificar rutinas críticas por uso, dependencia, impacto de negocio, frecuencia de errores y dificultad de mantenimiento.
Crear pruebas de caracterización antes de modificar comportamiento no documentado.
Dividir funciones grandes en unidades pequeñas sin cambiar contratos públicos cuando existen consumidores externos.
Sustituir bucles y cursores innecesarios por operaciones set-based cuando la mejora es demostrable.
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
¿Qué es PL/pgSQL dentro de PostgreSQL y por qué se utiliza como lenguaje procedural para crear funciones, procedimientos, triggers y lógica cercana al dato?
¿Para qué sirve PL/pgSQL en una empresa cuando ya existen aplicaciones backend, ORMs, pipelines ETL, herramientas BI y servicios que también procesan información?
¿Qué diferencia hay entre escribir SQL declarativo y escribir PL/pgSQL con variables, control de flujo, errores, cursores y transacciones?
¿Cuándo conviene usar PL/pgSQL para encapsular reglas, automatizar procesos, validar datos, ejecutar operaciones batch o proteger acceso a tablas?
¿Cuándo no conviene abusar de PL/pgSQL porque la lógica pertenece a la aplicación, a un servicio de dominio, a un pipeline o a una capa analítica?
¿Qué objetos se desarrollan habitualmente con PL/pgSQL: funciones, procedimientos, triggers, trigger functions, cursores, bloques `DO` y rutinas auxiliares?
¿Cómo se relaciona PL/pgSQL con PostgreSQL, extensiones, clientes SQL, aplicaciones, APIs, procesos de datos y entornos cloud gestionados?
¿Qué riesgos aparecen en proyectos PL/pgSQL mal gobernados: triggers invisibles, funciones enormes, permisos peligrosos, search_path inseguro y errores silenciados?
¿Qué conocimientos previos necesita un equipo para trabajar con PL/pgSQL de forma solvente: SQL, modelo relacional, transacciones, índices, permisos y EXPLAIN?
¿Qué criterios debe usar una empresa para decidir qué lógica vive en PL/pgSQL, qué se automatiza y qué debe documentarse como contrato técnico?
Tema 2: Entorno de trabajo PostgreSQL para desarrollo PL/pgSQL
Preparar un entorno PostgreSQL de laboratorio en local, Docker, servidor corporativo o servicio cloud, separando claramente prácticas y producción.
Configurar herramientas como `psql`, pgAdmin, DBeaver, DataGrip o clientes corporativos para ejecutar scripts, revisar errores y validar resultados.
Crear una base de datos de laboratorio con esquemas, tablas, constraints, índices, datos sintéticos y usuarios diferenciados.
Organizar scripts en repositorio separando DDL, DML, funciones, procedimientos, triggers, pruebas, migraciones y rollback.
Configurar permisos mínimos para que el usuario de laboratorio pueda crear objetos sin recibir privilegios administrativos innecesarios.
Usar `psql` para ejecutar scripts reproducibles, controlar variables, mostrar mensajes y validar despliegues desde terminal.
Revisar errores de compilación y ejecución de funciones mediante mensajes del cliente, `RAISE`, logs y vistas del catálogo.
Diferenciar ejecución interactiva, scripts versionados, migraciones automatizadas y cambios manuales no permitidos.
Crear convenciones de nombres para esquemas, funciones, procedimientos, triggers, tipos, variables y scripts de despliegue.
Documentar la preparación del entorno para que cualquier alumno pueda restaurar el laboratorio y repetir las prácticas sin dependencia manual.
Tema 3: Fundamentos del lenguaje PL/pgSQL
Crear bloques PL/pgSQL con secciones de declaración, cuerpo ejecutable y manejo de errores, entendiendo qué responsabilidad tiene cada parte.
Declarar variables, constantes, tipos derivados y registros con nombres que expresen intención funcional y no solo detalle técnico.
Usar asignaciones, expresiones, operadores, llamadas a funciones y resultados de consultas dentro de rutinas PL/pgSQL.
Comprender el alcance de variables, bloques anidados y nombres que pueden entrar en conflicto con columnas o parámetros.
Aplicar comentarios útiles para explicar reglas de negocio, decisiones no evidentes y restricciones operativas.
Usar `DO` blocks para pruebas puntuales, operaciones administrativas controladas o validación de lógica antes de crear funciones persistentes.
Diferenciar código experimental, código de despliegue, código productivo y scripts de soporte.
Evitar rutinas largas desde el principio, dividiendo responsabilidades en funciones pequeñas y contratos claros.
Probar fragmentos de lógica con datos sintéticos antes de incorporarlos a procesos críticos.
Construir un primer bloque PL/pgSQL que declare variables, ejecute una consulta, tome una decisión y registre un mensaje controlado.
Tema 4: Tipos de datos, variables y registros
Usar tipos escalares de PostgreSQL como `integer`, `numeric`, `text`, `boolean`, `date`, `timestamp`, `uuid`, `jsonb` y tipos propios del dominio.
Declarar variables basadas en columnas mediante `%TYPE` para reducir errores cuando cambia el tipo de una columna relevante.
Usar registros con `%ROWTYPE` o `record` cuando una rutina necesita trabajar con filas completas o resultados dinámicos.
Diferenciar tipos SQL persistentes, tipos compuestos, dominios y variables internas de PL/pgSQL.
Gestionar valores nulos con criterio, evitando comparaciones incorrectas y resultados inesperados en condiciones.
Controlar conversiones explícitas entre texto, fechas, números, UUIDs y JSON para evitar errores dependientes de formato o sesión.
Usar dominios y tipos compuestos cuando aportan semántica, validación o reutilización en el modelo de datos.
Evitar variables genéricas como `v_texto` o `v_dato` cuando el valor representa un concepto de negocio concreto.
Probar rutinas con valores nulos, extremos, tipos incorrectos y datos fuera de catálogo.
Crear una rutina que valida tipos, normaliza entradas y devuelve errores claros cuando recibe datos no aceptables.
Tema 5: Control de flujo: IF, CASE, LOOP y estructuras de decisión
Aplicar `IF`, `ELSIF` y `ELSE` para representar decisiones de negocio sin crear estructuras anidadas imposibles de mantener.
Usar `CASE` cuando la lógica depende de estados, códigos, categorías o reglas con varias salidas posibles.
Diseñar condiciones legibles que separen validación previa, reglas de negocio, excepciones funcionales y caminos alternativos.
Evitar condicionales extensos reemplazándolos por funciones auxiliares, tablas de configuración o reglas más declarativas cuando procede.
Usar `LOOP`, `WHILE`, `FOR` y `FOREACH` con criterio, entendiendo cuándo una iteración procedural aporta valor real.
Evitar bucles innecesarios cuando una operación set-based con SQL resuelve el problema de forma más simple y eficiente.
Controlar salidas de bucle, contadores, límites y condiciones de parada para evitar ejecuciones infinitas o procesos bloqueados.
Documentar reglas críticas cuando afectan a facturación, estados, permisos, cierres, validaciones o flujos regulatorios.
Probar cada rama con datos reales simulados, incluyendo casos límite, nulos y estados no esperados.
Construir un flujo de decisión empresarial con validación, clasificación, tratamiento de excepciones y resultado verificable.
Tema 6: SQL embebido en PL/pgSQL
Ejecutar consultas `SELECT INTO` gestionando correctamente ausencia de filas, múltiples filas y resultados esperados.
Usar `INSERT`, `UPDATE`, `DELETE` y `MERGE` desde PL/pgSQL con control de filas afectadas y validación de impacto.
Integrar variables de PL/pgSQL en sentencias SQL sin introducir ambigüedad entre nombres de columnas y nombres de variables.
Usar `FOUND`, `GET DIAGNOSTICS` y recuentos de filas para validar efectos de operaciones DML.
Diseñar operaciones idempotentes cuando una función o procedimiento puede reintentarse por fallo de integración o proceso batch.
Evitar consultas dentro de bucles cuando pueden resolverse con joins, CTEs, agregaciones o DML por conjuntos.
Crear rutinas que leen datos, aplican reglas y modifican registros con garantías de consistencia.
Controlar errores por constraints, claves duplicadas, referencias inexistentes o conversiones fallidas.
Revisar impacto de cada sentencia SQL embebida mediante `EXPLAIN`, estadísticas y pruebas con volumen representativo.
Construir una función que combina consulta, validación, actualización y respuesta estructurada para una operación de negocio.
Tema 7: Funciones PL/pgSQL: diseño, parámetros y contratos
Crear funciones con `CREATE FUNCTION`, parámetros tipados, valor de retorno claro y finalidad funcional bien definida.
Diseñar funciones pequeñas, cohesivas y reutilizables, evitando convertir cada función en un proceso completo de aplicación.
Usar parámetros `IN`, valores por defecto y nombres expresivos para mejorar legibilidad y mantenimiento.
Definir retornos escalares, compuestos, `TABLE`, `SETOF`, `record` o JSON según el contrato que necesita el consumidor.
Diferenciar funciones pensadas para consultas SQL, funciones internas de apoyo y funciones usadas como API controlada.
Evitar funciones con efectos secundarios inesperados cuando se usan dentro de consultas, filtros o vistas.
Marcar correctamente volatilidad con `IMMUTABLE`, `STABLE` o `VOLATILE` solo cuando se comprende su impacto.
Documentar cada función con propósito, parámetros, retorno, errores esperados, permisos y ejemplos de uso.
Probar funciones con entradas válidas, inválidas, nulas, límites y escenarios de permisos.
Construir una biblioteca de funciones PL/pgSQL con contratos claros, pruebas y documentación mínima.
Tema 8: Procedimientos almacenados y control transaccional
Crear procedimientos con `CREATE PROCEDURE` cuando se necesita ejecutar operaciones que no encajan bien como funciones de consulta.
Diferenciar funciones y procedimientos en PostgreSQL, especialmente por intención, forma de invocación y control transaccional.
Diseñar procedimientos para procesos batch, mantenimiento, cargas, cierres, consolidaciones o tareas administrativas controladas.
Gestionar parámetros de entrada y salida de forma predecible, evitando interfaces que ocultan demasiados efectos secundarios.
Controlar transacciones con criterio, entendiendo cuándo el procedimiento debe formar parte de una transacción superior.
Evitar commits o rollbacks improvisados en rutinas reutilizables si pueden romper flujos de aplicación o pipelines.
Registrar progreso y errores en procedimientos largos sin convertir el log en una fuente de datos sensibles.
Crear procedimientos reejecutables que soportan reintentos, cancelaciones y recuperación parcial.
Documentar cuándo un procedimiento puede ejecutarse manualmente, desde job, desde aplicación o desde pipeline.
Construir un procedimiento empresarial que procesa datos por lote, registra métricas y permite validación posterior.
Tema 9: Cursores, procesamiento fila a fila y alternativas set-based
Usar cursores explícitos cuando se requiere controlar lectura incremental, procesamiento complejo o interacción con lotes grandes.
Diferenciar `FOR record IN query`, cursores declarados, cursores con parámetros y cursores devueltos como `refcursor`.
Evitar cursores por costumbre cuando una única sentencia SQL puede resolver la operación con mejor rendimiento.
Diseñar procesamiento por lotes cuando el volumen exige controlar memoria, locks, tiempos de ejecución y recuperación.
Usar cursores para integraciones, transformaciones complejas o flujos donde cada fila tiene tratamiento diferenciado real.
Controlar cierre de cursores, errores intermedios y estado de ejecución para no dejar procesos en situación incierta.
Medir rendimiento frente a alternativas con CTEs, `INSERT INTO SELECT`, `UPDATE FROM`, `MERGE` o funciones de ventana.
Registrar progreso en procesos largos sin hacer commits arbitrarios que rompen atomicidad.
Probar cursores con pocos datos, muchos datos, errores por fila y cancelación controlada.
Refactorizar un proceso fila a fila hacia una solución set-based cuando el análisis demuestra mejora real.
Tema 10: Excepciones, errores y mensajes controlados
Usar bloques `EXCEPTION` para capturar errores esperados y convertirlos en respuestas comprensibles para el proceso consumidor.
Diferenciar errores de negocio, errores de validación, errores técnicos, errores de concurrencia y errores de permisos.
Usar `RAISE NOTICE`, `RAISE WARNING` y `RAISE EXCEPTION` con criterio, evitando ruido excesivo y mensajes inseguros.
Propagar errores críticos en lugar de ocultarlos con handlers genéricos que dejan datos inconsistentes.
Capturar información de diagnóstico con `GET STACKED DIAGNOSTICS` cuando se necesita registrar causa, detalle y contexto.
Crear códigos y mensajes funcionales estables cuando las aplicaciones consumidoras necesitan reaccionar a errores concretos.
Evitar incluir datos personales, secretos, tokens o payloads sensibles en mensajes de error o logs.
Diseñar una tabla de errores para procesos batch que permita revisar filas rechazadas, motivo y acción correctiva.
Probar errores igual que caminos de éxito, incluyendo constraints, duplicados, nulos, permisos y datos inválidos.
Construir un patrón de manejo de errores PL/pgSQL con logging, diagnóstico, relanzamiento y mensajes seguros.
Tema 11: Transacciones, bloqueos y consistencia de datos
Comprender cómo PL/pgSQL participa en transacciones PostgreSQL y cómo afecta a funciones, procedimientos, triggers y llamadas desde aplicación.
Diseñar rutinas que mantienen consistencia sin bloquear más filas ni más tiempo del necesario.
Usar `SELECT ... FOR UPDATE` cuando una operación requiere bloquear filas antes de modificarlas.
Gestionar concurrencia en procesos de reserva, asignación, colas, cambios de estado y operaciones sensibles.
Diferenciar errores de serialización, deadlocks, esperas por locks y conflictos lógicos de negocio.
Crear estrategias de reintento controlado cuando una operación puede fallar por concurrencia transitoria.
Evitar transacciones largas que mezclan consultas, llamadas externas, decisiones de usuario y DML crítico.
Analizar locks mediante vistas del sistema, logs, sesiones y pruebas con conexiones paralelas.
Documentar qué rutinas esperan ser llamadas dentro de una transacción externa y cuáles controlan su propia operación.
Construir un laboratorio de concurrencia con dos sesiones, bloqueos, rollback, reintento y validación de consistencia.
Tema 12: Triggers y trigger functions
Crear trigger functions en PL/pgSQL para reaccionar ante cambios en tablas o eventos de base de datos cuando existe una razón clara.
Diferenciar triggers `BEFORE`, `AFTER` e `INSTEAD OF`, así como triggers por fila y por sentencia.
Usar variables especiales como `NEW`, `OLD` y variables `TG_*` para entender contexto, operación y objeto que dispara el trigger.
Aplicar triggers para auditoría, validaciones localizadas, mantenimiento de columnas derivadas o integración controlada.
Evitar triggers con lógica de negocio extensa que sorprende a aplicaciones, procesos batch y equipos de soporte.
Controlar efectos secundarios, recursividad, orden de ejecución, rendimiento y dificultad de depuración.
Documentar triggers sobre tablas críticas para que ningún cambio desconozca efectos automáticos al insertar, actualizar o borrar.
Probar triggers con operaciones de una fila, operaciones masivas, errores, rollback y concurrencia.
Evaluar alternativas como constraints, generated columns, procedimientos explícitos, reglas de aplicación o jobs.
Refactorizar un trigger opaco hacia una solución más mantenible, probada y documentada.
Tema 13: Constraints, dominios y validación declarativa frente a procedural
Usar constraints como primera línea de defensa para integridad: claves primarias, claves externas, `UNIQUE`, `CHECK` y `NOT NULL`.
Crear dominios cuando un tipo de dato necesita una regla común reutilizable en varias columnas o tablas.
Decidir cuándo una validación debe ser declarativa y cuándo necesita PL/pgSQL por depender de lógica más compleja.
Evitar implementar en funciones reglas que PostgreSQL puede garantizar mejor mediante constraints.
Diseñar mensajes y pruebas que permitan detectar claramente qué regla de integridad ha fallado.
Revisar impacto de constraints en cargas masivas, migraciones, procesos batch y datos legacy.
Combinar constraints, funciones y triggers sin duplicar validaciones ni generar resultados contradictorios.
Documentar reglas de integridad para que desarrollo y negocio comprendan qué protege la base de datos.
Probar datos inválidos, duplicados, referencias rotas y estados prohibidos antes de publicar cambios.
Construir un modelo de validación donde constraints y PL/pgSQL colaboran sin solaparse innecesariamente.
Tema 14: SQL dinámico seguro con EXECUTE
Usar `EXECUTE` en PL/pgSQL cuando la estructura de la sentencia debe construirse dinámicamente en tiempo de ejecución.
Diferenciar SQL dinámico justificado de SQL dinámico usado por comodidad y con mayor riesgo de seguridad.
Construir sentencias dinámicas con `format()`, `%I`, `%L` y parámetros `USING` para reducir riesgos de inyección.
Validar nombres de tablas, columnas, esquemas y operaciones mediante listas permitidas antes de componer SQL.
Evitar concatenar valores de usuario, filtros o fragmentos de consulta sin validación estricta.
Diseñar utilidades de administración, auditoría o mantenimiento que trabajan con objetos variables de forma segura.
Registrar sentencias dinámicas en modo diagnóstico sin exponer datos sensibles ni credenciales.
Probar SQL dinámico con entradas válidas, inválidas, maliciosas, nulas y casos límite.
Revisar permisos y `SECURITY DEFINER` con especial cuidado cuando se combinan con SQL dinámico.
Construir una función de mantenimiento con SQL dinámico seguro, validación de identificadores y control de errores.
Tema 15: JSON, JSONB y lógica procedural
Usar `json` y `jsonb` para manejar payloads semiestructurados recibidos desde APIs, eventos, integraciones o procesos externos.
Extraer, validar y transformar propiedades JSON dentro de funciones PL/pgSQL sin perder control de tipos y errores.
Diseñar rutinas que reciben JSON como contrato de entrada, validan estructura y publican datos en tablas relacionales.
Evitar guardar todo en JSONB cuando el dato necesita joins, constraints, índices, trazabilidad o reglas relacionales fuertes.
Crear errores claros para payloads incompletos, propiedades ausentes, tipos incorrectos o formatos no permitidos.
Usar JSONB para metadatos flexibles, eventos, configuraciones o datos cambiantes cuando el caso lo justifica.
Indexar y consultar JSONB con criterio cuando ciertos campos se filtran o consultan de forma recurrente.
Documentar contratos JSON con versión, campos obligatorios, campos opcionales, compatibilidad y reglas de evolución.
Probar rutinas con documentos válidos, inválidos, arrays, objetos anidados, valores nulos y campos inesperados.
Construir una función PL/pgSQL que ingiere JSONB, valida reglas, registra errores y normaliza datos en tablas.
Tema 16: Arrays, rangos y tipos avanzados de PostgreSQL
Usar arrays cuando un conjunto de valores pertenece a una operación concreta, evitando reemplazar relaciones normalizadas sin motivo.
Iterar arrays con `FOREACH` y funciones auxiliares cuando se necesita lógica procedural sobre listas controladas.
Usar tipos de rango para representar intervalos de fechas, importes, numeraciones o periodos de vigencia.
Diseñar validaciones de solapamiento, disponibilidad, reservas, vigencias o planificación usando rangos y operadores nativos.
Crear tipos compuestos cuando una rutina necesita devolver o manipular estructuras de negocio más expresivas.
Evitar estructuras avanzadas si el equipo no podrá consultarlas, indexarlas, probarlas o mantenerlas correctamente.
Integrar arrays, rangos y tipos compuestos con funciones, procedimientos, vistas y contratos de aplicación.
Revisar índices adecuados para consultas con rangos, arrays o datos complejos.
Probar casos límite: arrays vacíos, rangos abiertos, rangos solapados, valores nulos y estructuras mal formadas.
Construir una rutina de planificación que valida disponibilidad usando rangos, arrays y errores controlados.
Tema 17: Funciones set-returning, RETURNS TABLE y APIs de lectura
Crear funciones que devuelven conjuntos de filas mediante `RETURNS TABLE`, `SETOF` o tipos compuestos.
Diseñar APIs de lectura en base de datos para exponer datos filtrados, calculados o protegidos sin dar acceso directo a tablas internas.
Controlar paginación, filtros, ordenación, permisos y estabilidad del contrato en funciones de lectura.
Evitar funciones set-returning que ocultan consultas lentas, joins excesivos o lógica difícil de optimizar.
Documentar columnas devueltas, significado funcional, consumidores previstos y cambios incompatibles.
Comparar funciones de lectura con vistas, materialized views, consultas directas o endpoints de aplicación.
Aplicar `RETURN QUERY` para expresar consultas complejas de forma clara dentro de PL/pgSQL.
Probar resultados con distintos filtros, usuarios, permisos, rangos de fechas y ausencia de datos.
Medir rendimiento cuando la función se usa desde aplicaciones, reporting, BI o integraciones recurrentes.
Construir una función de consulta empresarial con filtros, permisos, paginación y contrato documentado.
Tema 18: SECURITY DEFINER, search_path y seguridad de ejecución
Comprender la diferencia entre ejecución con privilegios del invocador y ejecución con privilegios del propietario de la función.
Usar `SECURITY DEFINER` solo cuando se necesita encapsular acceso controlado a objetos protegidos.
Proteger funciones `SECURITY DEFINER` fijando `search_path` y evitando que objetos maliciosos alteren la resolución de nombres.
Conceder `EXECUTE` sobre funciones o procedimientos en lugar de conceder acceso directo a tablas críticas cuando el diseño lo requiere.
Revocar permisos por defecto cuando una función sensible no debe ser ejecutable por roles amplios.
Validar entradas de funciones con privilegios elevados, especialmente si usan SQL dinámico o nombres de objetos.
Auditar ownership, grants y dependencias de funciones sensibles para detectar accesos excesivos.
Evitar que usuarios no autorizados puedan aprovechar funciones para escalar privilegios o leer datos indirectamente.
Documentar funciones de seguridad con propósito, owner, permisos, riesgos y pruebas asociadas.
Construir una API PL/pgSQL segura que permite una operación controlada sin exponer tablas internas.
Tema 19: Roles, privilegios y gobierno de acceso
Diseñar roles PostgreSQL para separar lectura, escritura, administración, ejecución de rutinas, reporting y procesos automatizados.
Conceder permisos sobre esquemas, tablas, secuencias, funciones y procedimientos con mínimos privilegios.
Evitar grants directos a usuarios personales cuando el acceso debería gestionarse por roles funcionales.
Revisar permisos efectivos para detectar privilegios heredados, grants obsoletos o accesos demasiado amplios.
Controlar `USAGE` sobre esquemas y secuencias además de permisos sobre tablas y rutinas.
Diseñar roles técnicos para aplicaciones, jobs, pipelines y usuarios interactivos con responsabilidades separadas.
Documentar matriz de permisos por entorno, esquema, objeto, rol y finalidad de negocio.
Probar escenarios de acceso permitido y denegado con usuarios de laboratorio.
Integrar permisos con despliegues versionados para que no dependan de cambios manuales posteriores.
Construir un modelo de seguridad con roles, grants, funciones controladas y pruebas de acceso.
Tema 20: Rendimiento de funciones y SQL embebido
Analizar que el rendimiento de PL/pgSQL depende en gran medida de las consultas SQL que ejecuta y del número de cambios de contexto.
Usar `EXPLAIN` y `EXPLAIN ANALYZE` para revisar planes, costes, filas estimadas, filas reales, índices y operaciones pesadas.
Detectar funciones llamadas fila a fila desde consultas grandes que generan degradaciones significativas.
Evitar bucles procedurales para operaciones que PostgreSQL puede resolver mejor mediante SQL set-based.
Revisar volatilidad, paralelismo, coste estimado y filas esperadas de funciones cuando afectan al optimizador.
Crear índices alineados con filtros, joins, ordenaciones y patrones reales de consulta usados por funciones.
Medir rendimiento con datos representativos, no solo con datasets pequeños de desarrollo.
Separar optimización de SQL, optimización de PL/pgSQL y optimización de modelo de datos para atacar la causa correcta.
Documentar mejoras de rendimiento con evidencia antes/después y riesgos asociados.
Optimizar una función lenta partiendo de métricas, plan de ejecución, refactorización y validación funcional.
Tema 21: Tablas temporales, staging y procesos por lotes
Crear tablas temporales para procesar datos intermedios, staging, validaciones o transformaciones por sesión.
Diferenciar tablas temporales, tablas staging persistentes, CTEs, vistas y estructuras en memoria según el proceso.
Diseñar cargas por etapas con recepción, validación, errores, transformación, publicación y resumen final.
Controlar índices temporales cuando un proceso intermedio necesita joins o búsquedas repetidas.
Evitar dejar tablas auxiliares persistentes sin owner, retención, limpieza o documentación.
Crear procesos reejecutables que no duplican datos ni dependen de estados manuales.
Registrar filas procesadas, rechazadas, actualizadas, duplicadas y pendientes para trazabilidad operativa.
Gestionar errores por fila frente a errores críticos que deben abortar todo el lote.
Coordinar staging con herramientas ETL, aplicaciones, colas, ficheros o integraciones externas.
Construir un proceso batch con staging, validaciones, errores, publicación y auditoría final.
Tema 22: Auditoría, logging e instrumentación
Diseñar tablas de auditoría para registrar operaciones críticas, cambios de estado, ejecuciones batch y acciones sensibles.
Separar auditoría funcional, logging técnico, trazabilidad de procesos y evidencias de cumplimiento.
Usar `RAISE` para mensajes de desarrollo y diagnóstico, sin sustituir un sistema de logging persistente cuando se necesita trazabilidad.
Registrar módulo, operación, usuario, fecha, clave de negocio, resultado, duración y número de filas afectadas.
Evitar guardar datos personales, secretos, tokens, payloads completos o información sensible innecesaria en logs.
Crear funciones auxiliares de logging reutilizables sin introducir dependencias circulares ni efectos transaccionales peligrosos.
Diseñar retención, limpieza, particionado o archivado de tablas de log para evitar crecimiento indefinido.
Relacionar logs de base de datos con logs de aplicación, IDs de correlación, jobs y procesos externos.
Crear consultas de auditoría para soporte, revisión de accesos, análisis de fallos y cumplimiento interno.
Construir un sistema de logging PL/pgSQL para procesos críticos con trazabilidad y retención controlada.
Tema 23: Extensiones y PL/pgSQL dentro del ecosistema PostgreSQL
Comprender cómo las extensiones amplían PostgreSQL y cómo pueden interactuar con funciones PL/pgSQL.
Usar extensiones aprobadas por la organización para UUIDs, criptografía, texto, auditoría, geodatos, colas o capacidades analíticas.
Evitar depender de extensiones no instaladas, no soportadas o no permitidas en entornos cloud gestionados.
Documentar extensiones requeridas por cada módulo, versión mínima, permisos y pasos de instalación.
Crear funciones PL/pgSQL que se apoyan en extensiones sin ocultar dependencias críticas.
Evaluar compatibilidad de extensiones entre PostgreSQL local, cloud gestionado, contenedores y entornos productivos.
Probar despliegues en entornos limpios para detectar dependencias no declaradas.
Revisar riesgos de seguridad y mantenimiento al introducir extensiones en bases corporativas.
Controlar actualizaciones de extensión como parte del ciclo de vida de la plataforma.
Construir un módulo que utiliza una extensión aprobada y documenta dependencia, permisos y pruebas.
Tema 24: Integración con aplicaciones, ORMs y APIs
Diseñar funciones y procedimientos consumibles desde aplicaciones .NET, Java, Python, Node.js u otros backends corporativos.
Decidir cuándo una aplicación debe llamar a una función PL/pgSQL y cuándo debe usar SQL parametrizado, ORM o servicio intermedio.
Evitar acoplar aplicaciones a detalles internos de tablas, triggers o rutinas auxiliares no pensadas como contrato público.
Diseñar contratos de entrada y salida claros: parámetros, tipos, errores, resultados, permisos y transacciones.
Gestionar llamadas desde ORMs como Entity Framework, Hibernate, SQLAlchemy o herramientas equivalentes sin romper mantenibilidad.
Controlar transacciones cuando aplicación y PL/pgSQL participan en la misma operación funcional.
Devolver resultados estructurados mediante tablas, tipos compuestos o JSON según necesidades del consumidor.
Probar integraciones con usuarios técnicos, permisos reales de ejecución, errores esperados y datos de laboratorio.
Documentar funciones públicas como APIs internas de datos, con ejemplos de llamada y condiciones de uso.
Construir una integración de ejemplo donde una aplicación consume una función PL/pgSQL como operación controlada.
Tema 25: PL/pgSQL para ETL, ELT y pipelines de datos
Usar PL/pgSQL para validar, transformar y publicar datos dentro de procesos ELT cuando el dato ya reside en PostgreSQL.
Diseñar pipelines por etapas con staging, validación, normalización, enriquecimiento, publicación y auditoría.
Integrar funciones y procedimientos con orquestadores, jobs, Airflow, dbt, scripts, cron o herramientas corporativas.
Evitar concentrar demasiada lógica procedural dentro de PostgreSQL cuando el pipeline necesita escalado externo o procesamiento distribuido.
Crear controles de calidad: duplicados, nulos, rangos, referencias, formatos, reglas de negocio y conciliaciones.
Registrar métricas de pipeline: duración, filas recibidas, aceptadas, rechazadas, modificadas y pendientes.
Diseñar procesos reejecutables con claves de lote, estados, checkpoints y recuperación ante fallo.
Usar transacciones y locks con cuidado para no bloquear cargas o consumos analíticos.
Documentar dependencias entre tablas, procesos, vistas, funciones y consumidores.
Construir un pipeline ELT con PL/pgSQL, staging, validación, errores y publicación controlada.
Tema 26: Materialized views, refresh y procesos de consumo
Usar materialized views cuando una consulta costosa necesita persistirse para reporting, APIs o consumo recurrente.
Diseñar funciones o procedimientos que controlan refresco, validación, bloqueo, logging y comunicación de estado.
Evaluar `REFRESH MATERIALIZED VIEW` y refresco concurrente según disponibilidad, índices y requisitos de consumo.
Evitar materializar datos sin owner, calendario, retención, criterios de frescura o consumidores claros.
Coordinar materialized views con procesos ETL, reporting, dashboards, cargas nocturnas y ventanas operativas.
Controlar permisos para que consumidores lean vistas materializadas sin acceder a tablas internas sensibles.
Medir impacto del refresco sobre recursos, locks, tiempos de respuesta y otros procesos.
Crear validaciones post-refresh para asegurar recuentos, fechas máximas, totales y consistencia básica.
Documentar dependencia entre materialized views, tablas base, funciones y procesos de actualización.
Construir un proceso de publicación analítica con materialized view, refresh controlado, logging y validación.
Tema 27: Particionamiento, mantenimiento y operaciones sobre grandes volúmenes
Comprender cuándo el particionamiento ayuda a gestionar tablas grandes por fecha, rango, lista o hash.
Diseñar funciones auxiliares para crear particiones, validar particiones futuras, mover datos o gestionar mantenimiento.
Evitar particionar por moda cuando el volumen, patrón de acceso o operación no lo justifica.
Controlar consultas sobre tablas particionadas para que aprovechen pruning y no escaneen datos innecesarios.
Gestionar mantenimiento de particiones antiguas, archivado, borrado, retención y cumplimiento.
Diseñar procesos PL/pgSQL que operan por partición para reducir locks, tiempos y consumo de recursos.
Revisar impacto de índices, constraints, triggers y claves sobre tablas particionadas.
Probar cargas, consultas y mantenimiento con volúmenes representativos antes de publicar.
Documentar estrategia de particionamiento con criterios, owner, calendario y procedimiento de emergencia.
Construir una rutina de mantenimiento para tabla particionada con creación, validación y limpieza controlada.
Tema 28: Notificaciones, LISTEN/NOTIFY y procesos reactivos
Usar `LISTEN` y `NOTIFY` para notificar eventos ligeros a aplicaciones o procesos que escuchan cambios.
Diferenciar notificaciones de PostgreSQL de colas empresariales completas, entendiendo límites de fiabilidad y persistencia.
Diseñar triggers o funciones que emiten notificaciones solo cuando el caso requiere reacción inmediata y controlada.
Evitar payloads grandes o sensibles dentro de notificaciones, usando identificadores y consulta posterior cuando procede.
Coordinar aplicaciones consumidoras para reconexión, reintento, deduplicación y tratamiento de eventos perdidos.
Documentar canales, payloads, productores, consumidores y finalidad de cada notificación.
Probar notificaciones con varias sesiones, fallos de conexión, transacciones abortadas y alto volumen.
Evaluar alternativas como colas externas, outbox pattern o CDC cuando se necesita entrega robusta.
Usar PL/pgSQL para implementar un outbox sencillo cuando la arquitectura lo requiere.
Construir un caso reactivo con trigger, notificación, payload controlado y consumidor de prueba.
Tema 29: Testing de funciones, procedimientos y triggers
Diseñar pruebas repetibles para funciones, procedimientos, triggers, permisos, errores y procesos batch.
Crear datos sintéticos que cubran escenarios de éxito, error, nulos, duplicados, límites, permisos y rollback.
Usar scripts de prueba o frameworks como pgTAP cuando la organización requiere suites automatizadas de base de datos.
Validar resultados mediante recuentos, comparaciones, tablas esperadas, errores capturados y cambios persistidos.
Probar triggers con operaciones de una fila, múltiples filas, transacciones abortadas y cargas masivas.
Evitar pruebas que dependen de datos productivos cambiantes, hora actual no controlada o ejecución en orden implícito.
Integrar pruebas PL/pgSQL en pipelines CI/CD para detectar regresiones antes de desplegar.
Separar pruebas unitarias de funciones puras, pruebas de integración sobre tablas y pruebas end-to-end de procesos completos.
Documentar escenarios cubiertos y huecos pendientes en reglas críticas de negocio.
Construir una suite de pruebas para un paquete funcional de rutinas PL/pgSQL con datos controlados y rollback.
Tema 30: Versionado, migraciones y CI/CD de código PL/pgSQL
Versionar código PL/pgSQL en Git con scripts reproducibles, orden de ejecución y trazabilidad de cambios.
Separar creación de objetos, alteraciones, datos maestros, grants, pruebas, rollback y documentación.
Usar herramientas de migración como Flyway, Liquibase, Sqitch, dbmate o soluciones corporativas equivalentes cuando estén aprobadas.
Diseñar migraciones idempotentes solo cuando aporta valor, evitando ocultar errores reales de despliegue.
Validar sintaxis, permisos, dependencias y objetos inválidos antes de aplicar cambios en entornos superiores.
Integrar pruebas, linters, revisión de formato y comprobaciones de seguridad en pipelines.
Evitar cambios manuales en producción que no quedan reflejados en repositorio ni proceso de aprobación.
Documentar releases con objetos afectados, riesgos, pruebas ejecutadas, rollback y responsables.
Coordinar cambios PL/pgSQL con cambios de aplicación, APIs, informes, jobs y consumidores externos.
Construir un pipeline de laboratorio que despliega funciones, ejecuta pruebas y valida permisos.
Tema 31: Calidad de código, estándares y revisión técnica
Definir estándares de nombres para funciones, procedimientos, triggers, variables, parámetros, tipos, errores y tablas auxiliares.
Revisar código por legibilidad, modularidad, tamaño, duplicación, manejo de errores, seguridad y rendimiento.
Evitar funciones enormes, triggers opacos, SQL dinámico inseguro, `search_path` no controlado y errores silenciados.
Crear checklist de revisión para cambios PL/pgSQL: contrato, permisos, transacción, tests, EXPLAIN, logging y rollback.
Documentar rutinas públicas con propósito, parámetros, retorno, errores, permisos y ejemplos de llamada.
Separar lógica de negocio, lógica técnica, validación, logging y transformación para facilitar mantenimiento.
Revisar impacto de cambios en consumidores, vistas, jobs, aplicaciones, pipelines y herramientas BI.
Usar formateo consistente y comentarios útiles para que el código sea revisable por más de una persona.
Establecer Definition of Done para rutinas PL/pgSQL antes de aceptar un pull request.
Construir una guía corporativa de PL/pgSQL con ejemplos correctos, anti-patrones y criterios de revisión.
Tema 32: Refactorización y modernización de PL/pgSQL legacy
Auditar código existente para detectar funciones largas, triggers invisibles, lógica duplicada, permisos excesivos y SQL lento.
Identificar rutinas críticas por uso, dependencia, impacto de negocio, frecuencia de errores y dificultad de mantenimiento.
Crear pruebas de caracterización antes de modificar comportamiento no documentado.
Dividir funciones grandes en unidades pequeñas sin cambiar contratos públicos cuando existen consumidores externos.
Sustituir bucles y cursores innecesarios por operaciones set-based cuando la mejora es demostrable.
Pensado para quienes deben dominar PL/pgSQL en su día a día
Desarrolladores backend
Este curso encaja con desarrolladores que trabajan con aplicaciones conectadas a PostgreSQL y necesitan comprender mejor qué lógica puede vivir dentro de la base de datos. Aprenderán a diseñar funciones, procedimientos, triggers y APIs internas sin convertir la base en una caja negra ni duplicar reglas entre backend, scripts y procesos batch.
DBAs y administradores PostgreSQL
Los perfiles de administración podrán reforzar su capacidad para revisar código PL/pgSQL, diagnosticar errores, analizar bloqueos, optimizar funciones, controlar permisos, auditar cambios y acompañar a equipos de desarrollo con criterios sólidos de rendimiento, seguridad y operación.
Data Engineers y Analytics Engineers
Los equipos de datos podrán usar PL/pgSQL para automatizar cargas, validar reglas, transformar información, procesar staging tables, controlar errores y construir procesos reproducibles. El curso les ayuda a escribir lógica cercana al dato sin caer en soluciones lentas, frágiles o difíciles de mantener.
Arquitectos de software y datos
Los perfiles de arquitectura podrán decidir qué responsabilidades conviene ubicar en PL/pgSQL, cuáles deben mantenerse en servicios o pipelines y cómo gobernar la frontera entre base de datos, aplicación, integración y consumo analítico.
Equipos de mantenimiento y modernización
Los equipos que heredan bases PostgreSQL con funciones antiguas, triggers poco documentados, scripts manuales o lógica procedural crítica aprenderán a diagnosticar, probar, refactorizar y documentar sin romper comportamiento productivo.
QA técnico y responsables de calidad
Los perfiles de calidad podrán validar funciones, procedimientos, triggers, permisos, errores y procesos de datos con escenarios repetibles. La formación les permite conectar pruebas de base de datos con CI/CD, control de cambios y criterios de aceptación técnica.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en PL/pgSQL
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Parte desde las preguntas fundamentales de PL/pgSQL, pero avanza hacia un nivel profesional. Es recomendable conocer SQL, tablas, joins, transacciones y conceptos básicos de PostgreSQL para aprovecharlo bien.
Sí. PL/pgSQL forma parte del ecosistema oficial de PostgreSQL para desarrollar funciones, procedimientos, triggers y lógica procedural dentro de la base de datos. La documentación actual de PostgreSQL mantiene un capítulo específico dedicado a PL/pgSQL.
Sí. El curso se plantea sobre PostgreSQL 18 o sobre la versión corporativa soportada por la empresa. PostgreSQL publica documentación vigente para la versión actual 18 y mantiene versiones soportadas anteriores.
Sí. Se trabajan funciones, procedimientos, parámetros, tipos de retorno, contratos, errores, transacciones, permisos, testing, documentación y consumo desde aplicaciones o procesos de datos.
Sí. El curso incluye trigger functions, variables especiales, triggers por fila y sentencia, auditoría, validaciones, riesgos, rendimiento, pruebas y alternativas. PostgreSQL documenta PL/pgSQL como lenguaje válido para definir trigger functions.
Sí. Se trabajan `EXPLAIN`, `EXPLAIN ANALYZE`, índices, SQL embebido, cursores, operaciones set-based, locks, funciones llamadas desde consultas, materialized views y procesos batch.
Sí. Se profundiza en roles, grants, ownership, `SECURITY DEFINER`, `SECURITY INVOKER`, `search_path`, SQL dinámico seguro, protección de datos sensibles y pruebas de acceso.
Sí. JSONB se incluye como parte importante del curso para contratos de entrada, APIs, eventos, validación de payloads, normalización, consultas, índices y procesos de integración.
Sí. Se trabaja versionado en Git, migraciones, herramientas como Flyway o Liquibase si la empresa las usa, pruebas automatizadas, rollback, revisión de permisos y pipelines de validación.
Sí. El curso contempla PostgreSQL self-managed y servicios gestionados como Amazon RDS, Aurora, Azure Database for PostgreSQL o Cloud SQL, teniendo en cuenta permisos, extensiones y limitaciones operativas.
No. Es una formación corporativa práctica para desarrollo, DBA, datos y arquitectura. Puede reforzar conocimientos útiles de PostgreSQL, pero no sustituye una preparación oficial de certificación.
Sí. Al tratarse de una formación corporativa en bases de datos, PostgreSQL, desarrollo PL/pgSQL, seguridad, rendimiento, datos y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Parte desde las preguntas fundamentales de PL/pgSQL, pero avanza hacia un nivel profesional. Es recomendable conocer SQL, tablas, joins, transacciones y conceptos básicos de PostgreSQL para aprovecharlo bien.
Sí. PL/pgSQL forma parte del ecosistema oficial de PostgreSQL para desarrollar funciones, procedimientos, triggers y lógica procedural dentro de la base de datos. La documentación actual de PostgreSQL mantiene un capítulo específico dedicado a PL/pgSQL.
Sí. El curso se plantea sobre PostgreSQL 18 o sobre la versión corporativa soportada por la empresa. PostgreSQL publica documentación vigente para la versión actual 18 y mantiene versiones soportadas anteriores.
Sí. Se trabajan funciones, procedimientos, parámetros, tipos de retorno, contratos, errores, transacciones, permisos, testing, documentación y consumo desde aplicaciones o procesos de datos.
Sí. El curso incluye trigger functions, variables especiales, triggers por fila y sentencia, auditoría, validaciones, riesgos, rendimiento, pruebas y alternativas. PostgreSQL documenta PL/pgSQL como lenguaje válido para definir trigger functions.
Sí. Se trabajan `EXPLAIN`, `EXPLAIN ANALYZE`, índices, SQL embebido, cursores, operaciones set-based, locks, funciones llamadas desde consultas, materialized views y procesos batch.
Sí. Se profundiza en roles, grants, ownership, `SECURITY DEFINER`, `SECURITY INVOKER`, `search_path`, SQL dinámico seguro, protección de datos sensibles y pruebas de acceso.
Sí. JSONB se incluye como parte importante del curso para contratos de entrada, APIs, eventos, validación de payloads, normalización, consultas, índices y procesos de integración.
Sí. Se trabaja versionado en Git, migraciones, herramientas como Flyway o Liquibase si la empresa las usa, pruebas automatizadas, rollback, revisión de permisos y pipelines de validación.
Sí. El curso contempla PostgreSQL self-managed y servicios gestionados como Amazon RDS, Aurora, Azure Database for PostgreSQL o Cloud SQL, teniendo en cuenta permisos, extensiones y limitaciones operativas.
No. Es una formación corporativa práctica para desarrollo, DBA, datos y arquitectura. Puede reforzar conocimientos útiles de PostgreSQL, pero no sustituye una preparación oficial de certificación.
Sí. Al tratarse de una formación corporativa en bases de datos, PostgreSQL, desarrollo PL/pgSQL, seguridad, rendimiento, datos y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.