Todo lo que has escrito hasta ahora es una consulta: se envía, se ejecuta y se olvida. Esta lección va de lo contrario — código con nombre que vive dentro de la base de datos y que se invoca como si fuera parte del lenguaje. Aquí acabará viviendo la confirmación de pedido que en 09-03 escribiste a mano, con su BEGIN, sus cuatro sentencias y su COMMIT, y que hasta ahora dependía de que quien la ejecutara no se dejara ningún paso.

Verás la diferencia real entre una función y un procedimiento en PostgreSQL 11+, lo justo de PL/pgSQL para escribir algo útil sin convertir esto en un curso de programación, y tres ejemplos de TiendaVerde en orden de dificultad que terminan en sp_confirmar_pedido. Y, sobre todo, la discusión honesta: qué gana un equipo poniendo lógica en la base de datos, qué pierde, y dónde está la frontera. Porque esta es la herramienta del módulo que más fácil es usar mal.

1. Función frente a procedimiento
2. CREATE FUNCTION con LANGUAGE sql
3. PL/pgSQL en una tabla de referencia
4. Parámetros, tipos de retorno, sobrecarga y borrado
5. fn_total_pedido: una función escalar
6. fn_ventas_por_categoria: una función que devuelve tabla
7. sp_confirmar_pedido: el procedimiento de 09-03
8. Volatilidad y SECURITY DEFINER
9. La discusión honesta: qué poner dentro y qué no
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Hasta PostgreSQL 10 solo existían funciones, y se usaban para todo. Desde la 11 hay también procedimientos, y la confusión entre ambos es constante. La tabla que la resuelve:

La línea divisoria es el control de transacciones. Una función se ejecuta dentro de la transacción de quien la llama; si esa transacción se deshace, todo lo que hizo la función se deshace con ella. Un procedimiento llamado con CALL fuera de una transacción explícita puede confirmar por su cuenta, lo que permite escribir un proceso por lotes que confirma cada mil filas sin mantener una transacción gigante abierta (09-01).

La regla práctica: si devuelve un dato, función; si hace un trabajo, procedimiento.

La forma más sencilla no necesita ningún lenguaje procedimental: es una consulta con nombre y parámetros.

433,70 + 156,48 + 137,77 = 727,95 €: las cifras por país que ya calculaste en 07-04, ahora encapsuladas. Cuatro detalles de sintaxis que se repetirán toda la lección:

• $$ ... $$ delimita el cuerpo. Es la dollar quoting de 01-03: dentro puedes escribir comillas simples sin escaparlas. Si el cuerpo contiene $$, usa una etiqueta: $fn$ ... $fn$.
• Los parámetros se nombran con prefijo (p_pais) por convención, para que no choquen con nombres de columna. Si un parámetro se llamara pais, PostgreSQL no sabría a qué te refieres en el WHERE.
• RETURNS NUMERIC declara el tipo. Con LANGUAGE sql, el resultado es el de la última sentencia.
• STABLE es la volatilidad (apartado 8).

(Todas las funciones y procedimientos de esta lección son ejemplos: no forman parte del esquema canónico de TiendaVerde de 01-06.)

LANGUAGE sql no sabe decidir ni repetir. Para eso está PL/pgSQL, el lenguaje procedimental que trae PostgreSQL de serie. Esto es lo esencial —lo justo para escribir algo útil— y no hace falta más para esta lección:

Dos avisos que ahorran horas. El primero: BEGIN y END en PL/pgSQL delimitan un bloque de código, no una transacción; la palabra coincide y confunde a todo el mundo. El segundo: un bloque con EXCEPTION crea internamente un SAVEPOINT (09-03) y tiene coste, así que no envuelvas en EXCEPTION un bucle de un millón de iteraciones si no lo necesitas.

RETURNS TABLE(...) frente a RETURNS SETOF record: la primera declara los nombres y tipos de las columnas dentro de la función, y quien la llama escribe simplemente SELECT * FROM fn(...). La segunda obliga a describir la estructura en cada llamada —SELECT * FROM fn(...) AS t(id INT, nombre TEXT)—, lo que es incómodo y frágil. Usa RETURNS TABLE salvo que la forma del resultado dependa de verdad de los argumentos.

Sobre la sobrecarga, una advertencia: es cómoda pero se vuelve traicionera con los tipos. fn(1) y fn(1.0) pueden resolverse a funciones distintas, y DROP FUNCTION fn sin firma da function name "fn" is not unique. Prefiere nombres distintos a sobrecargar, salvo que la sobrecarga sea evidente.

El primer ejemplo, y el que más se usará: el total de un pedido, con la expresión canónica de importe.

Y aquí está su gracia: se usa como una columna más, dentro de cualquier consulta.

Los cuatro totales coinciden con los de 07-04: el pedido 12 es el ticket máximo (66,90 €) y el 20 el mínimo (22,60 €).

Y aquí está el peligro, dicho pronto: SELECT id, fn_total_pedido(id) FROM pedidos ejecuta la función una vez por fila — 20 consultas independientes contra lineas_pedido. Es exactamente la subconsulta correlacionada de 07-02, ahora escondida detrás de un nombre bonito. Para un informe de 20 pedidos da igual; para uno de dos millones, es la diferencia entre 200 ms y media hora. Una función escalar dentro de un SELECT masivo es un JOIN disfrazado, y casi siempre es mejor escribir el JOIN (o usar la vista de 10-01).

Con RETURNS TABLE, una función se comporta como una tabla parametrizada — algo a medio camino entre una vista y una consulta suelta, y que las vistas no pueden hacer porque una vista no acepta parámetros.

Suman 603,52 €, la facturación de 2025. Y con SELECT * FROM fn_ventas_por_categoria(2026) salen solo cuatro categorías —Bebidas 48,73 €, Alimentación 40,60 €, Cosmética natural 28,10 € e Higiene personal 7,00 €—, que suman los 124,43 € de 2026: en los dos primeros meses del año no se ha vendido nada de Hogar sostenible.

Como cualquier tabla, se puede filtrar y unir: SELECT * FROM fn_ventas_por_categoria(2025) WHERE facturacion > 100; devuelve tres filas.

Cuándo función y cuándo vista (10-01): si el resultado no depende de ningún parámetro, vista. Si depende de un argumento —el año, el país, un rango de fechas—, función que devuelve tabla. Y si el parámetro solo sirve para filtrar una columna que la vista ya expone, vista y WHERE, que el planificador optimiza mejor.

Este es el destino que 09-03 y 09-05 anunciaron. La confirmación de un pedido son varias operaciones que deben ir juntas: crear la cabecera, insertar las líneas, descontar el stock comprobando que no quede negativo y marcar el pedido como pagado. Si algo falla, no debe quedar nada a medias.

La llamada, con el caso feliz y el caso de fallo:

Y el pedido 22 no existe. Esa es toda la lección del apartado: el RAISE EXCEPTION abortó la transacción, y con ella se deshizo la cabecera que ya se había insertado. La atomicidad de 09-02 está garantizada por construcción, no por la disciplina de quien llama. Un CALL fuera de una transacción explícita se ejecuta en su propia transacción implícita, así que el procedimiento es atómico sin escribir BEGIN ni COMMIT.

Compáralo con lo que tenías en 09-03: allí, la aplicación debía abrir la transacción, ejecutar las cuatro sentencias en el orden correcto, comprobar el UPDATE N del stock y decidir si confirmaba. Cuatro sitios donde equivocarse, multiplicados por cada aplicación que confirme pedidos. Aquí hay uno.

(Este procedimiento modifica los datos. Si lo pruebas, recarga después el script de 01-06 para volver a las 20 filas de pedidos y a los stocks originales.)

El COMMIT explícito tiene un caso claro: el proceso por lotes. Un procedimiento que recalcula un millón de filas y confirma cada mil evita mantener una transacción de horas —con el coste en VACUUM y bloqueos que explicó 09-01:

Es exactamente lo que una función no puede hacer, y la razón por la que los procedimientos se añadieron al motor.

Toda función declara —explícita o implícitamente— cuánto puede fiarse el planificador de ella:

Que VOLATILE sea el valor por omisión es el error silencioso más caro de la lección. Una función que solo lee y no declara nada se evalúa fila a fila y no puede indexarse, así que aquí se cierra la promesa de 08-02: un índice de expresión como CREATE INDEX ix_prod_lower ON productos (lower(nombre)); exige que la función sea IMMUTABLE. Si no lo es, PostgreSQL responde functions in index expression must be marked IMMUTABLE — porque un índice guarda resultados precalculados y solo tiene sentido si esos resultados no cambian.

Marca STABLE toda función de solo lectura e IMMUTABLE toda función de cálculo puro. Y no mientas al planificador: declarar IMMUTABLE algo que lee una tabla produce resultados incorrectos difíciles de diagnosticar.

SECURITY DEFINER. Por omisión una función corre con los permisos de quien la llama (SECURITY INVOKER). Con SECURITY DEFINER corre con los de quien la creó, lo que permite dar acceso controlado a datos que el usuario no puede leer directamente. Es potente y es una superficie de ataque: mal escrita, con un search_path manipulable, es una escalada de privilegios de manual. Los permisos, los roles y cómo blindar estas funciones son materia de 11-03.

Esto es lo más valioso de la lección, y donde la mayoría de los tutoriales callan.

Y el criterio, que es lo que hay que llevarse:

La postura equilibrada, y la que sostiene la mayoría de los equipos hoy: poco código en la base de datos, y del bueno. Restricciones y CHECK siempre; vistas y funciones de cálculo, sin problema; procedimientos para lo que de verdad exija atomicidad o proceso masivo. Lo que no funciona es ninguno de los dos extremos: ni una aplicación anémica que solo llama a doscientos procedimientos, ni una base de datos tratada como un almacén tonto en la que ninguna regla se puede garantizar.

Nota de dialecto: aquí es donde más divergen los motores.

Motor	Lenguaje	Peculiaridad
PostgreSQL	PL/pgSQL (y PL/Python, PL/Perl, PL/v8…)	CREATE FUNCTION / CREATE PROCEDURE; CALL; cuerpo entre $$
MySQL 8	SQL/PSM	Hace falta DELIMITER // antes de crear el procedimiento, porque el ; interno cortaría la sentencia
SQL Server	T-SQL	CREATE PROCEDURE ... AS BEGIN ... END, EXEC, @variables, TRY...CATCH
Oracle	PL/SQL	El antecesor de PL/pgSQL: se parecen mucho, pero los paquetes (PACKAGE) no tienen equivalente
SQLite	—	No tiene procedimientos ni funciones almacenadas. Solo funciones definidas por la aplicación al abrir la conexión

• Llamar a un procedimiento con SELECT. No es una expresión: CALL sp_confirmar_pedido(...). Y al revés, CALL sobre una función da error.
• Esperar que un COMMIT dentro de una función funcione. No puede: cannot commit while a subtransaction is active o invalid transaction termination. Solo los procedimientos, y solo si el CALL no está dentro de una transacción explícita.
• Dejar la volatilidad por omisión. Todo es VOLATILE si no dices nada: se reevalúa fila a fila y no sirve para un índice de expresión (functions in index expression must be marked IMMUTABLE). Marca STABLE lo que solo lee.
• Llamar a una función escalar sobre millones de filas. Es una correlacionada disfrazada: una ejecución por fila. Reescríbela como JOIN, vista o función que devuelva tabla.
• Dar a un parámetro el mismo nombre que a una columna. La ambigüedad se resuelve a favor del parámetro y el WHERE deja de filtrar. Prefijo p_ siempre.
• Confundir el BEGIN de PL/pgSQL con el de una transacción. Delimita un bloque de código. La transacción es la del llamante.
• Usar EXCEPTION WHEN OTHERS THEN NULL. Silencia todos los errores, incluidos los que jamás debiste silenciar. Captura excepciones concretas y vuelve a lanzar lo que no sepas tratar.
• Escribir ELSEIF o ELSE IF. En PL/pgSQL es ELSIF.
• Consejo: guarda el código en el repositorio, en ficheros .sql con CREATE OR REPLACE, y despliégalo con las migraciones. Una función que solo existe en producción no existe.
• Consejo: empieza por LANGUAGE sql. Si no necesitas decidir ni repetir, no uses PL/pgSQL: la versión SQL pura es más corta, más rápida y el planificador puede integrarla en la consulta que la llama.
• Consejo: RAISE NOTICE es tu depurador. No hay mucho más, y con RAISE NOTICE 'v_stock = %', v_stock; en los puntos clave se resuelve el 90 % de los problemas.

Escribe fn_puntuacion_media(p_producto_id), que devuelva la puntuación media de un producto redondeada a dos decimales, o NULL si no tiene reseñas. (1) Elige LANGUAGE sql o plpgsql y justifica. (2) Declara la volatilidad correcta. (3) Úsala en una consulta que liste los 20 productos con su media, y comprueba que el aceite (producto 1) sale con 5.00, el arroz con 4.50 y once productos con NULL.

Sobre sp_confirmar_pedido, responde razonando y comprueba después. (1) Si el segundo producto de la lista no tiene stock, ¿queda insertada la primera línea? ¿Y la cabecera del pedido? ¿Por qué? (2) ¿Qué pasaría si quitaras el FOR UPDATE del SELECT sobre productos y dos clientes confirmaran a la vez la última unidad de matcha? (3) ¿Podrías convertirlo en función en lugar de procedimiento? ¿Qué perderías?

El equipo discute dónde poner cuatro reglas de TiendaVerde. Decide, con el criterio del apartado 9, si van en la base de datos o en la aplicación, y con qué herramienta exacta:

1. "El precio de venta nunca puede ser negativo."
2. "Al confirmar un pedido hay que enviar un correo de confirmación al cliente."
3. "Cada noche hay que recalcular el ranking de productos más vendidos del mes."
4. "Un cliente no puede tener más de tres pedidos pendientes a la vez."

Solución 1

(4 primeras de 20 filas; siguen el detergente y el cepillo con 4.00, el tomate y las bolsas con 3.00, la kombucha con 2.00 y once productos con NULL.)

1. LANGUAGE sql: no hay ninguna decisión ni bucle, solo una consulta. Es más corta y el planificador puede integrarla en la consulta que la llama, cosa que con plpgsql no ocurre. 2. STABLE: lee tablas, así que no puede ser IMMUTABLE; y no escribe, así que declararla VOLATILE sería desperdiciar optimizaciones. 3. El AVG sobre un conjunto vacío devuelve NULL sin necesidad de ningún IF — y aquí NULL es lo correcto: "no hay opiniones" no es lo mismo que "cero estrellas" (04-03).

Solución 2

1. No queda nada: ni la línea, ni la cabecera. El RAISE EXCEPTION aborta la transacción entera, y como el CALL se ejecutó en su propia transacción implícita, se deshace todo lo hecho desde el principio del procedimiento — incluida la primera línea, que ya estaba insertada, y el UPDATE que ya había descontado su stock. Es la atomicidad de 09-02 aplicada sin que nadie tenga que acordarse de escribir ROLLBACK. Sí queda consumido el valor de la secuencia de pedidos.id, por lo de 09-05: nextval no es transaccional.

2. Sería la actualización perdida de 09-04, exactamente. Sin FOR UPDATE, ambas sesiones leerían stock = 1, ambas pasarían el IF v_stock < cantidad, y ambas insertarían su línea: se venderían dos unidades de una. El CHECK (stock >= 0) de la tabla salvaría los muebles en este caso concreto —el segundo UPDATE fallaría al intentar dejar el stock en −1—, pero eso es suerte, no diseño. Con FOR UPDATE, la segunda sesión espera, relee stock = 0 y lanza su excepción de stock insuficiente, que es el mensaje correcto para el cliente.

3. Sí, y funcionaría igual de bien en este caso, porque toda la lógica cabe en una sola transacción: bastaría CREATE FUNCTION ... RETURNS INTEGER devolviendo el id del pedido, y ejecutarla con SELECT. Lo que perderías es la capacidad de hacer COMMIT intermedios, irrelevante aquí pero decisiva si algún día el procedimiento tuviera que confirmar mil pedidos por lotes. Se gana algo a cambio: una función se puede usar dentro de una consulta. La elección honesta es la del apartado 1: esto hace un trabajo, no calcula un valor, así que procedimiento.

Solución 3

La cuarta es la interesante y no tiene respuesta única: la pregunta correcta no es "¿se puede?" sino "¿qué pasa si alguien se la salta?". Si la respuesta es "datos corruptos", va en la base de datos; si es "una experiencia de compra rara", va en la aplicación.

Código que vive en la base de datos, con sus dos caras:

• Función frente a procedimiento: una función devuelve un valor, se llama con SELECT, se puede usar dentro de una consulta y no controla transacciones; un procedimiento se llama con CALL, no devuelve nada (salvo por INOUT) y sí puede hacer COMMIT/ROLLBACK. Si devuelve un dato, función; si hace un trabajo, procedimiento.
• LANGUAGE sql basta para encapsular una consulta con parámetros, y es la primera opción. PL/pgSQL añade DECLARE, IF/ELSIF, FOR ... IN SELECT, RETURN QUERY, RAISE NOTICE/EXCEPTION y el bloque EXCEPTION WHEN — con el aviso de que su BEGIN no es el de una transacción.
• RETURNS TABLE(...) convierte una función en una tabla parametrizada, que es lo que una vista no puede ser. Si no hay parámetros, vista; si los hay, función.
• Los tres ejemplos: fn_total_pedido (escalar, con los tickets de 42,10, 64,88, 66,90 y 22,60 €), fn_ventas_por_categoria (tabla, 603,52 € en 2025 y 124,43 € en 2026) y sp_confirmar_pedido, donde vive por fin la lógica de 09-03: inserta, descuenta stock con FOR UPDATE, lanza RAISE EXCEPTION si falta y deja la base intacta si algo falla.
• La volatilidad importa: VOLATILE es el valor por omisión y significa "reevalúame en cada fila"; IMMUTABLE es requisito para un índice de expresión (08-02) y STABLE es lo correcto para casi toda función de solo lectura. SECURITY DEFINER da poder y abre una superficie de ataque (11-03).
• Y la discusión honesta: una llamada en lugar de seis viajes, lógica junto a los datos, atomicidad garantizada y reutilización, frente a versionado difícil, pruebas incómodas, lógica en dos sitios, portabilidad nula y escalado atado al servidor de BD. La postura sensata es poco código en la base de datos, y del bueno.

Queda una pregunta que este esquema no responde: ¿y si la lógica tiene que ejecutarse sin que nadie la llame? Un procedimiento hay que invocarlo, y basta con que una aplicación escriba directamente en la tabla para saltárselo entero. En la lección siguiente, triggers, verás código que se dispara solo cuando algo pasa: BEFORE o AFTER de un INSERT, UPDATE o DELETE, con NEW y OLD, y con la capacidad de modificar o cancelar la operación en curso. Con él construirás la auditoría de cambios de precio, mantendrás al día un total desnormalizado, impedirás que un cliente reseñe un producto que no ha comprado —la regla que 09-02 dejó fuera del alcance de un CHECK— y descontarás stock automáticamente. Y verás sus peligros con el mismo detalle, porque un trigger es la única pieza del curso capaz de hacer que un UPDATE haga algo que tú no escribiste.