Funciones heredadas e historial

OmniDB ha pasado por varias vidas muy distintas — un proyecto universitario, una aplicación web en Python/Django con un ecosistema de complementos, y ahora una aplicación Go en un único binario. Esta página es el lugar para todo lo que existió pero ya no existe: qué era, por qué no va a volver, y dónde encontrarlo si todavía lo necesita. Para conocer la historia del proyecto en sí, consulte Introducción.

Cronología de versiones

Era	Qué era
Original (ASP. NET/C#)	Proyecto final de grado en la Universidad Federal de Paraná — la primera herramienta en trazar una línea común entre los metadatos de PostgreSQL, MySQL/MariaDB, Oracle, SQLite, Firebird y SQL Server.
OmniDB (Python/Django)	La versión de larga trayectoria que la mayoría conoce: una aplicación web Django con un espacio de trabajo basado en navegador y, desde la 2.9 en adelante, un sistema de complementos en Python para extensiones de la comunidad. El desarrollo en el repositorio original OmniDB/OmniDB se detuvo alrededor de 2020.
Resurgimiento 2025–2026 (3.1.x)	El proyecto se retomó: base de código modernizada, seguridad mejorada, soporte nativo para macOS Apple Silicon, y una revisión completa de la documentación — en ese momento aún sobre el backend de Python/Django.
Reescritura en Go (3.6.x)	Todo el backend se reescribió de Python/Django a Go y se distribuyó como un único binario nativo. El runtime de Python, y todo lo que solo tenía sentido dentro de él — incluido el sistema de complementos —, se eliminó.
Migración a Wails (completada)	El shell de escritorio pasó de NW.js a Wails (Go) — un binario más pequeño, sin Chromium empaquetado, y la aplicación ahora usa directamente el webview nativo del sistema operativo.

El sistema de complementos (eliminado)

El sistema de complementos se ha eliminado como parte de la reescritura 3.6.x del backend de Python/Django a Go, y ya no está disponible.

OmniDB 2.9 introdujo un sistema de complementos que permitía a los usuarios escribir código Python enganchado a distintas partes de la interfaz, para añadir sus propias funciones sin volver a desplegar toda la aplicación. Ese mecanismo dependía de importar dinámicamente módulos Python arbitrarios en el proceso del servidor en ejecución — algo sin equivalente en un binario Go compilado — y deliberadamente no se conservó. Dado que ya nunca podría hacer nada útil, el diálogo «Plugins» y su entrada de menú, así como los endpoints de la API detrás de él, se eliminaron por completo de la aplicación en lugar de mantenerlos como un stub permanentemente vacío.

Si dependía de un complemento en concreto, actualmente no hay forma compatible de portarlo. Cualquier cosa que un complemento hiciera antes accediendo directamente a la base de datos normalmente todavía puede hacerse hoy a través del editor SQL normal, los fragmentos de código (snippets), o una unidad de monitorización personalizada.

Depurador paso a paso de PL/pgSQL (eliminado)

OmniDB 2.3.0 añadió un depurador interactivo paso a paso para funciones y procedimientos PL/pgSQL — puntos de interrupción, inspección de variables en vivo y estadísticas de ejecución por línea. Dependía de una extensión C personalizada de PostgreSQL (omnidb_plugin) que se enganchaba a la API interna de complementos de PL/pgSQL, cargada mediante shared_preload_libraries (lo que requiere reiniciar el servidor), además de un esquema omnidb dedicado y acceso local sin contraseña para una segunda conexión de base de datos exclusiva para depuración.

El depurador se ha eliminado, junto con sus entradas de menú de árbol «Debug Function»/«Debug Procedure». Nunca se portó durante la reescritura 3.6.x en Go, y la propia extensión omnidb_plugin no se ha tocado desde 2020. Más allá del coste continuo de mantener funcionando una extensión C de internals de PostgreSQL en cada nueva versión mayor de PostgreSQL, fundamentalmente no puede funcionar en absoluto contra ningún PostgreSQL gestionado o en la nube (RDS, Cloud SQL, Supabase, Neon y similares) — ninguno de ellos permite una entrada personalizada de shared_preload_libraries — por lo que una parte grande y creciente de los usuarios actuales nunca habría podido usarlo, sin importar lo bien mantenido que estuviera.

Escribir y ejecutar funciones PL/pgSQL en sí no se ve afectado — consulte Escritura de funciones PL/pgSQL. Si necesita recorrer paso a paso la ejecución de PL/pgSQL contra su propio servidor PostgreSQL autoalojado, el código fuente original de omnidb_plugin sigue disponible en el historial del repositorio original, o puede usar pldebugger (el equivalente activamente mantenido que usa pgAdmin) directamente, fuera de OmniDB.

pglogical (eliminado)

pglogical era una extensión de PostgreSQL que proporcionaba un sistema eficiente de replicación lógica. El antiguo complemento omnidb-pglogical añadía nodos de vista de árbol y acciones basadas en plantillas SQL (crear nodo, gestionar conjuntos de replicación, crear suscripciones, etc.) para trabajar con él — todo construido sobre el sistema de complementos eliminado anteriormente, por lo que ya no carga.

Postgres-BDR (eliminado)

Postgres-BDR («Bi-Directional Replication») era la extensión multi-maestro de 2ndQuadrant para PostgreSQL. El antiguo complemento omnidb-bdr le daba el mismo tipo de integración en la vista de árbol que pglogical. La misma historia: era un complemento, y el sistema de complementos del que dependía ha desaparecido.

Postgres-XL (eliminado)

Postgres-XL era un fork de PostgreSQL masivamente paralelo y escalable horizontalmente (GTM + coordinador + nodos de datos). El antiguo complemento omnidb-xl añadía nodos de vista de árbol conscientes del clúster para él. También era un complemento, y también ha desaparecido.

Por qué ninguno de estos va a volver

Los tres eran integraciones ligeras basadas en complementos para forks/extensiones de PostgreSQL nicho, en su mayoría sin mantenimiento upstream — ni pglogical, ni BDR, ni Postgres-XL tuvieron versiones nuevas significativas en los últimos años. Reconstruir el propio sistema de complementos en Go supondría diseñar un mecanismo de extensión completamente nuevo (complementos compilados, un runtime de scripting o una API de hooks) para una audiencia pequeña y menguante, algo que no ha sido prioritario frente al resto de la reescritura en Go. Nada en la reescritura impide conectarse a un clúster pglogical/BDR/XL como una base de datos PostgreSQL normal y gestionar los objetos de replicación a mano a través del editor SQL normal o de la pestaña de consola — simplemente no se obtienen los nodos dedicados de vista de árbol ni los atajos de plantillas SQL que los complementos solían añadir.

Dónde encontrar las versiones antiguas

Las versiones clásicas de OmniDB (hasta ~2020) con soporte completo de complementos siguen disponibles, sin mantenimiento, en el repositorio original:

github.com/OmniDB/OmniDB — la aplicación original y su archivo de versión.
github.com/OmniDB/plugins — el código fuente de los propios complementos pglogical/BDR/XL.

Ninguno de los dos repositorios recibe actualizaciones. Si necesita gestión de pglogical, BDR o Postgres-XL hoy en día, una versión antigua de ahí — ejecutada contra una base de datos acorde a su época — es su mejor opción; no hay ruta de migración desde esa configuración hacia el actual OmniDB basado en Go.