El Sistema de Extensiones
Las extensiones de PostgreSQL son el mecanismo sancionado para añadir tipos, operadores, funciones, métodos de acceso a índices y workers de fondo a una base de datos en ejecución sin parchear o bifurcar el propio servidor.
Cada extensión que un equipo habilita se convierte en una parte permanente y versionada del catálogo de esa base de datos, por lo que comprender la maquinaria subyacente a CREATE EXTENSION es más importante que memorizar la sintaxis del comando.
Esta página construye el modelo mental del sistema de extensiones en su conjunto: qué es realmente una extensión en disco, cómo decide el servidor cuándo se necesita cargar código, cómo se relacionan las versiones entre sí y dónde se encuentra el límite de confianza.
Resumen
- Una extensión es un paquete versionado de objetos SQL (y opcionalmente código compilado) que PostgreSQL rastrea como una única unidad de dependencia en su catálogo.
- Por Qué Importa: Las extensiones permiten que una base de datos crezca con nuevas capacidades (búsqueda vectorial, tipos geoespaciales, criptografía, programación) sin una bifurcación del servidor, mientras sigue siendo actualizable, auditable y reversible.
- Conceptos Clave: archivo de control, script de extensión,
shared_preload_libraries,pg_extension, grafo de dependencias, límite de confianza. - Cuándo Usar: Utiliza este modelo mental siempre que decidas si una extensión necesita un reinicio, si es seguro concederla a un rol de aplicación o por qué una ruta de actualización está bloqueada.
- Limitaciones / Compensaciones: Las extensiones son por base de datos, no globales, y cualquier extensión que contenga código C se ejecuta dentro del proceso del servidor con el mismo espacio de memoria que el núcleo de PostgreSQL.
- Temas Relacionados: Mecánica de
CREATE EXTENSION, extensiones confiables vs. no confiables, rutas de actualización de extensiones, gobernanza de la lista blanca de extensiones.
Fundamentos
Una extensión no es un paquete descargado como lo es un paquete npm o pip; es un conjunto de archivos que ya deben existir en el sistema de archivos de la máquina antes de que se ejecute cualquier SQL.
Como mínimo, una extensión incluye un archivo de control (extname.control) que declara su nombre, versión predeterminada, comentario y si es o no relocable.
Junto al archivo de control se encuentran uno o más scripts SQL que definen los objetos reales: tipos, funciones, operadores, conversiones o rutinas de soporte de índices.
Algunas extensiones añaden una tercera pieza, una biblioteca compartida compilada (un archivo .so en Linux), a la que las definiciones de funciones del script SQL apuntan a través de AS 'MODULE_PATHNAME'.
CREATE EXTENSION lee el archivo de control, ejecuta el script de instalación coincidente dentro de una transacción y registra el resultado como una única fila en el catálogo pg_extension.
Esa fila del catálogo es lo que hace que una extensión sea un objeto de primera clase y rastreable, en lugar de un montón de funciones sueltas que alguien ejecutó una vez.
pg_available_extensions muestra qué archivos de control puede ver el servidor en disco, mientras que pg_extension muestra qué se ha instalado realmente en la base de datos actual.
Una analogía útil es una arquitectura de plugins: el archivo de control es el manifiesto, el script SQL es el instalador y la biblioteca compartida (cuando está presente) es el binario del plugin compilado.
Dado que el manifiesto y el instalador son solo archivos, que una extensión esté "disponible" no dice nada sobre si el paquete subyacente del sistema operativo se instaló alguna vez en ese host.
Mecánica e Interacciones
El servidor trata el código de las extensiones de dos maneras muy diferentes dependiendo de cuándo necesita ejecutarse.
Las extensiones puramente SQL (tipos, funciones escritas en SQL o PL/pgSQL, vistas) no necesitan nada más allá de la búsqueda normal del catálogo que ya ocurre para cualquier objeto de base de datos.
Las extensiones respaldadas por una biblioteca compartida de C se cargan dinámicamente en su primer uso dentro de un proceso backend, de la misma manera que se resuelve cualquier otro módulo cargable.
Un pequeño subconjunto de extensiones necesita algo más: registran workers de fondo, segmentos de memoria compartida personalizados o hooks que deben existir antes de que el postmaster acepte su primera conexión.
Esas extensiones deben nombrarse en shared_preload_libraries en postgresql.conf, porque el postmaster lee esa configuración una vez al inicio y asigna memoria compartida en consecuencia.
Es por esto que añadir una entrada a shared_preload_libraries requiere un reinicio completo del servidor, mientras que la mayoría de las llamadas a CREATE EXTENSION no lo hacen.
La relación de dependencia entre extensiones no es solo documentación informal, ya que PostgreSQL la registra en pg_depend, y CREATE EXTENSION puede declarar una lista REQUIRES en su archivo de control para que las extensiones dependientes se instalen automáticamente o fallen claramente.
El versionado sigue la misma lógica de grafo: cada extensión tiene una versión predeterminada más un conjunto de scripts de actualización nombrados como extname--1.0--1.1.sql, y ALTER EXTENSION ... UPDATE recorre esa cadena paso a paso en lugar de saltar directamente a la versión de destino.
Si falta un enlace en esa cadena, por ejemplo, un paquete envía 1.0 y 1.2 pero no el script 1.0--1.1 o 1.1--1.2, la actualización simplemente no puede continuar hasta que se instale el script faltante.
-- El grafo de dependencias se puede consultar, no es solo conceptual
SELECT dep.refobjid::regclass AS depends_on,
ext.extname AS extension
FROM pg_depend dep
JOIN pg_extension ext ON ext.oid = dep.objid
WHERE dep.deptype = 'e';Las extensiones relocables se pueden mover a un esquema diferente después de la instalación, mientras que las no relocables (PostGIS es un ejemplo común) codifican referencias calificadas por esquema en su script de instalación y resisten un movimiento limpio.
Consideraciones Avanzadas y Aplicaciones
A escala, el sistema de extensiones se convierte tanto en un problema de gobernanza como técnico, porque cada extensión respaldada por C se ejecuta dentro del mismo proceso y espacio de memoria que el núcleo de PostgreSQL.
Ese espacio de memoria compartida es exactamente por qué las extensiones no confiables históricamente requerían superusuario, ya que una biblioteca compartida maliciosa o defectuosa puede leer memoria arbitraria del servidor, bloquear el postmaster o eludir la seguridad a nivel de fila por completo.
El mecanismo de extensiones confiables de PostgreSQL reduce ese riesgo al permitir que un rol no superusuario que simplemente tiene el privilegio CREATE en la base de datos de destino instale extensiones específicas y auditadas, sin otorgar a ese rol la capacidad de cargar código C arbitrario.
Los proveedores de nube gestionados se apoyan en este mismo límite desde la otra dirección, curando pg_available_extensions a una lista blanca verificada para que los clientes nunca vean archivos de control para extensiones que la plataforma no ha revisado.
Los conflictos de extensiones son otra preocupación avanzada: dos extensiones pueden definir un operador o una función con el mismo nombre en el mismo esquema, y la que se instala en segundo lugar simplemente falla o oculta silenciosamente a la primera dependiendo del orden de búsqueda.
La orquestación de actualizaciones se agrava en un clúster, ya que un conjunto de réplicas gestionado por Patroni necesita binarios de bibliotecas compartidas coincidentes en todos los nodos antes de que ALTER EXTENSION UPDATE se ejecute en cualquier lugar, o la réplica corre el riesgo de cargar una versión de biblioteca que su stream WAL no espera.
El grafo de dependencias también es importante para la replicación lógica, donde una base de datos suscriptora debe tener instalados los mismos tipos y funciones proporcionados por la extensión antes de poder aplicar cambios que hagan referencia a ellos.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Extensión puramente SQL (sin biblioteca compartida) | Sin reinicio, superficie de ataque mínima, fácil de auditar | No puede hacer nada a nivel C como métodos de acceso a índices personalizados | Funciones de utilidad, envoltorios de tipos simples |
| Extensión C sin precarga | Funcionalidad rica (tipos, operadores, métodos de índice) | Se ejecuta en proceso, amplía la superficie de revisión de seguridad | pgvector, PostGIS, pgcrypto |
Extensión C con shared_preload_libraries | Habilita workers de fondo y hooks de memoria compartida | Requiere reinicio planificado para la instalación y cada cambio de configuración | pg_stat_statements, pg_cron |
| Extensión confiable | Instalable sin superusuario, autoservicio más rápido | Solo las extensiones explícitamente marcadas como confiables califican | Equipos que delegan instalaciones limitadas a propietarios de aplicaciones |
Conceptos Erróneos Comunes
- "CREATE EXTENSION descarga y compila el código" - no lo hace; el archivo de control, los scripts SQL y cualquier biblioteca compartida deben estar ya presentes en el host a través de un paquete del sistema operativo, y
CREATE EXTENSIONsolo registra y ejecuta lo que ya está allí. - "Cada extensión necesita un reinicio" - solo las extensiones listadas en
shared_preload_librarieslo hacen, porque esa configuración se lee una vez al inicio del postmaster, mientras que la mayoría de las extensiones se activan inmediatamente dentro de la sesión actual. - "Las extensiones son globales para el servidor" - se instalan por base de datos, por lo que un clúster puede tener
vectoren una base de datos y nada adicional en otra, aunque ambas compartan el mismo binario de PostgreSQL. - "Confiable significa seguro contra cualquier riesgo" - confiable solo significa que la extensión no requiere superusuario para instalarse, no que esté libre de errores, problemas de licencia o CVEs.
- "Eliminar una extensión solo elimina sus propios objetos" -
DROP EXTENSIONpuede afectar en cascada a cualquier cosa que dependa de esos objetos, incluyendo vistas, índices y otras extensiones, a menos que revisepg_dependprimero.
Preguntas Frecuentes
¿Qué hay realmente dentro de una extensión de PostgreSQL?
Un archivo de control que describe los metadatos de la extensión, uno o más scripts SQL de instalación/actualización y, opcionalmente, una biblioteca compartida compilada a la que hacen referencia las definiciones de funciones del script SQL.
¿Dónde viven los archivos de extensión en el disco?
Los archivos de control y los scripts SQL se encuentran en el directorio informado por pg_config --sharedir, mientras que las bibliotecas compartidas compiladas se encuentran en pg_config --pkglibdir.
¿Por qué algunas extensiones necesitan un reinicio y otras no?
Solo las extensiones que registran workers de fondo, segmentos de memoria compartida personalizados o hooks de inicio necesitan aparecer en shared_preload_libraries, y esa configuración solo se lee cuando se inicia el postmaster.
¿Es CREATE EXTENSION lo mismo que instalar software?
No, registra y ejecuta scripts SQL contra un conjunto de archivos ya presente; el paquete subyacente del sistema operativo aún debe instalarse por separado antes de que el comando SQL pueda tener éxito.
¿Cómo sabe PostgreSQL que una extensión depende de otra?
A través de la cláusula REQUIRES en un archivo de control combinada con filas de catálogo en pg_depend, que tanto el planificador como los comandos DROP/ALTER consultan.
¿Qué sucede si falta un script de actualización entre dos versiones?
ALTER EXTENSION ... UPDATE no puede omitir versiones, por lo que un script intermedio faltante (por ejemplo, 1.1--1.2.sql) bloquea la cadena de actualización hasta que se instale ese archivo.
¿Se instalan las extensiones por base de datos o por clúster?
Por base de datos, con la única excepción de configuraciones a nivel de clúster como shared_preload_libraries que se aplican a todas las bases de datos de la instancia independientemente de cuáles usen realmente la extensión.
¿Cuál es la diferencia entre una extensión confiable y una no confiable?
Una extensión confiable puede ser instalada por cualquier rol con privilegio CREATE en la base de datos, mientras que una no confiable todavía requiere superusuario porque su script de instalación o biblioteca compartida conlleva más riesgo.
¿Pueden dos extensiones entrar en conflicto entre sí?
Sí, si definen objetos con el mismo nombre en el mismo esquema, y PostgreSQL resuelve la colisión a través de las reglas normales de ruta de búsqueda y nomenclatura en lugar de cualquier arbitraje consciente de extensiones.
¿Por qué los proveedores de nube gestionados limitan qué extensiones puedo instalar?
Debido a que las extensiones respaldadas por C se ejecutan dentro del mismo proceso que el motor de la base de datos, el proveedor cura pg_available_extensions solo para lo que su equipo ha revisado en cuanto a estabilidad y seguridad.
¿El sistema de extensiones se relaciona con lenguajes procedurales como PL/pgSQL?
Sí, los lenguajes procedurales se instalan y rastrean a través del mismo mecanismo pg_extension que cualquier otra extensión.
¿Es seguro simplemente ejecutar DROP EXTENSION cuando ya no necesito una?
Solo después de verificar pg_depend para los objetos que hacen referencia a ella, ya que una eliminación en cascada puede eliminar silenciosamente vistas, índices u otras extensiones construidas sobre ella.
Relacionados
- Fundamentos de Extensiones - la receta paso a paso de
CREATE EXTENSIONyshared_preload_librariespara la cual esta página construye un modelo mental - Extensiones Confiables vs. No Confiables - una mirada más profunda al límite de confianza introducido anteriormente
- Ruta de Actualización de Extensiones - el procedimiento operativo para recorrer el grafo de actualización de versiones
- Política de Lista Blanca de Extensiones - prácticas de gobernanza para decidir qué extensiones están aprobadas
- Mejores Prácticas para Extensiones - la lista de verificación operativa que complementa este modelo conceptual
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PostGIS 3.5+, pgbouncer 1.x, y Patroni 3.x.