UNION con tipos incompatibles: convierte cada posición a un tipo común

Ejemplo: dos columnas a cada lado, pero tipos incompatibles en PostgreSQL

La forma de ambas ramas es idéntica: orden y valor. El conflicto está en la segunda posición, donde una rama produce un entero y la otra texto.

SELECT 1 AS orden,
       42::integer AS valor
UNION ALL
SELECT 2,
       'sin-dato'::text;

Con las reglas de resolución de tipos de PostgreSQL, integer y text no forman una categoría común para esa columna y la unión se rechaza. En SQL Server una combinación equivalente puede intentar convertir el texto al tipo de mayor prioridad y fallar si el valor no es convertible. MySQL, en cambio, documenta que SELECT 1 UNION SELECT 'a' es válido y construye un resultado capaz de contener ambos valores.

El mismo SQL puede comportarse distinto según el motor

Comprobación local: SQLite acepta valores heterogéneos

La siguiente consulta se ejecutó localmente con SQLite durante esta revisión. El resultado muestra que la misma columna contiene un entero en una fila y texto en otra.

WITH combinados AS (
  SELECT 1 AS orden, 42 AS valor
  UNION ALL
  SELECT 2, 'sin-dato'
)
SELECT orden,
       valor,
       typeof(valor) AS tipo
FROM combinados
ORDER BY orden;

Este resultado no contradice a PostgreSQL o SQL Server: SQLite tiene un sistema de tipos diferente. Si tu consulta debe viajar entre motores, define el tipo de salida de forma deliberada en vez de depender de coerciones implícitas.

Corrección: decide el significado de la columna y convierte hacia ese contrato

Antes de añadir CAST, pregunta qué representa la posición. Si valor es una etiqueta que a veces contiene números y a veces texto, convertir ambas ramas a texto puede ser correcto. Si representa un importe, convertir 'sin-dato' a texto solo oculta un problema de calidad: deberías limpiar el dato o representarlo como NULL.

SELECT 1 AS orden,
       CAST(42 AS VARCHAR(20)) AS valor
UNION ALL
SELECT 2,
       CAST('sin-dato' AS VARCHAR(20));

La conversión explícita documenta la intención y reduce diferencias entre motores. Aun así, el tipo elegido debe representar el dominio real del dato; no uses texto como salida universal solo para silenciar errores.

Método de diagnóstico

1. Cuenta las columnas de cada rama. Si no coinciden, corrige primero la forma de la fila.
2. Compara los tipos posición por posición. No te fijes solo en los nombres de alias.
3. Define qué significa cada posición. ¿Es un importe, una fecha, un identificador o una etiqueta?
4. Revisa las reglas del motor. Una coerción implícita aceptada por MySQL o SQLite puede fallar en PostgreSQL o SQL Server.
5. Usa CAST solo hacia un tipo semánticamente correcto. Si el origen contiene valores inválidos, corrige los datos o trátalos de forma explícita.

Error frecuente: convertir todo a texto para que UNION deje de fallar

Práctica correctiva

WITH actuales(codigo, precio) AS (
  VALUES ('A', 19.90), ('B', 25.00)
),
legacy(codigo, precio_texto) AS (
  VALUES ('C', '12.50'), ('D', '30.00')
)
SELECT codigo,
       CAST(precio AS DECIMAL(10,2)) AS precio
FROM actuales
UNION ALL
SELECT codigo,
       CAST(precio_texto AS DECIMAL(10,2))
FROM legacy
ORDER BY codigo;

Conceptos relacionados

Fuentes técnicas

La resolución de tipos y las diferencias entre motores de esta guía se contrastaron con documentación primaria:

• PostgreSQL: resolución de tipos en UNION, CASE y construcciones relacionadas
• MySQL 8.4: columnas y tipos en operaciones de conjuntos
• SQL Server: UNION y compatibilidad de tipos
• SQL Server: prioridad de tipos de datos
• SQLite: consultas SELECT compuestas
• SQLite: tipado dinámico y afinidad