Antes de aprender qué significa cada sentencia de SQL conviene aprender cómo está escrita. Igual que en cualquier idioma, existen reglas ortográficas y gramaticales que, si desconoces, te harán perder horas frente a mensajes de error crípticos. Esta lección desmonta una sentencia SQL en sus piezas elementales —palabras clave, identificadores, literales, operadores y expresiones— y te explica las reglas del lenguaje: el punto y coma, el tratamiento de mayúsculas y minúsculas, los comentarios, las convenciones de estilo profesional, la precedencia de operadores y, muy importante, cómo interpretar un mensaje de error de PostgreSQL para localizar el fallo en segundos.

Aquí usaremos sentencias muy simples como vehículo. No es el objetivo aprender aún qué hace SELECT o WHERE —eso es el módulo 2—; el objetivo es entender las reglas ortográficas con las que se escribe cualquier sentencia SQL.

1. Anatomía de una sentencia SQL
2. El punto y coma
3. Mayúsculas y minúsculas
4. Identificadores entrecomillados
5. Comentarios
6. Convenciones de estilo y formato
7. Operadores y su precedencia
8. Literales: cadenas, números, fechas, booleanos y NULL
9. Cómo leer un mensaje de error de PostgreSQL
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Toda sentencia SQL se compone de un puñado de tipos de elemento. Veamos una y etiquetemos cada pieza:

Merece la pena detenerse en la diferencia entre palabra clave e identificador, porque es la fuente de la mitad de los errores de principiante:

• Una palabra clave forma parte del lenguaje. No la eliges tú: SELECT siempre significa lo mismo.
• Un identificador es un nombre que alguien puso a un objeto: la tabla productos se llama así porque quien diseñó TiendaVerde lo decidió.

Reglas de los identificadores en PostgreSQL:

• Empiezan por letra o _, y siguen con letras, dígitos, _ o $.
• Longitud máxima: 63 caracteres (lo que sobra se trunca en silencio).
• No pueden coincidir con una palabra reservada... salvo que los entrecomilles (sección 4).
• Se recomienda snake_case en minúsculas: lineas_pedido, fecha_pedido, referido_por_id.

Una expresión es cualquier cosa que se evalúa y produce un valor. Puedes comprobarlo sin ninguna tabla:

En PostgreSQL, SELECT sin FROM es perfectamente válido y es la mejor forma de experimentar con expresiones sueltas. Lo usaremos mucho en esta lección.

El ; marca el final de una sentencia. Su papel es doble:

1. Separar varias sentencias en un mismo fichero o bloque.
2. Indicar al cliente que ya puede enviar la sentencia al servidor.

Esas son tres sentencias independientes. Sin los puntos y coma, PostgreSQL leería SELECT 1 SELECT 2 SELECT 3 e informaría de un error de sintaxis.

Si en psql pulsas Intro sin haber cerrado la sentencia, el símbolo del sistema cambia:

Ese guion (-#) significa "sigo esperando". No es un error: puedes repartir una sentencia en tantas líneas como quieras.

Consejo: ponlo siempre. Es gratis y te ahorra depurar por qué un script se ejecutó "a medias".

Aquí hay dos reglas distintas que conviene no mezclar.

Estas cuatro sentencias son idénticas para PostgreSQL:

Aun así, la convención universal es escribir las palabras clave en MAYÚSCULAS, porque hace la consulta mucho más legible: de un vistazo distingues la estructura del lenguaje de los nombres de tu esquema.

Esta es la parte que sorprende. El estándar SQL dice que los identificadores sin comillas deben plegarse a mayúsculas; PostgreSQL, por razones históricas, los pliega a minúsculas. El efecto práctico es que:

es exactamente lo mismo que:

porque PostgreSQL convierte internamente Nombre → nombre y Productos → productos.

Compáralo entre motores:

Moraleja práctica: usa siempre minúsculas y snake_case en tus identificadores. Así tu SQL se comporta igual en todos los motores y te ahorras el problema entero.

Ojo: la insensibilidad a mayúsculas afecta a la sintaxis, no a los datos. Los valores sí distinguen:

Si rodeas un identificador con comillas dobles, PostgreSQL lo toma literalmente: respeta mayúsculas, espacios y caracteres especiales.

Y a partir de ahí, cualquier referencia a la segunda obliga a repetir las comillas:

Ese error es de los más desconcertantes: la tabla existe, se ve en \dt, y aun así el motor dice que no la encuentra. La causa es siempre la misma: alguien la creó entrecomillada con mayúsculas.

Regla del curso: todas las tablas y columnas de TiendaVerde están en minúsculas y snake_case precisamente para que nunca necesites comillas dobles. La única excepción aceptable serán los alias de presentación.

Y no lo olvides: comillas dobles = identificador; comillas simples = cadena de texto. No son intercambiables (volveremos a ello en la sección 8).

SQL admite dos formas de comentario:

En PostgreSQL los comentarios de bloque se pueden anidar, algo que no todos los motores permiten:

Buenas prácticas con los comentarios:

• Comenta el porqué, no el qué. -- filtramos activos sobra si la línea ya dice WHERE activo = TRUE. En cambio -- los inactivos son productos descatalogados que conservamos por histórico sí aporta.
• Encabeza los scripts largos con un bloque que explique qué hacen y quién los mantiene.
• Usa -- para desactivar una línea mientras depuras, pero limpia esos restos antes de dar la consulta por buena.

SQL ignora los saltos de línea y los espacios de más, así que el formato es enteramente para las personas. Y sí, importa: una consulta de veinte líneas mal formateada es imposible de revisar.

Antes (todo en una línea, palabras clave en minúsculas, sin estructura):

Después (una cláusula por línea, palabras clave en mayúsculas, alineación clara):

Las dos hacen exactamente lo mismo. La segunda se puede leer, revisar y modificar.

Convenciones que sigue este curso (y que son las más extendidas del sector):

Fíjate en que la tabla se llama resenas y no reseñas. Es deliberado: evitar ñ y tildes en identificadores previene problemas de codificación, de portabilidad entre motores y de escritura en teclados no españoles.

La trampa está en /: si ambos operandos son enteros, la división es entera.

Con solo escribir 10.0 en lugar de 10 cambias el tipo del literal y con él el resultado. Es una fuente clásica de descuadres al calcular porcentajes.

<> es la forma estándar de "distinto"; != funciona en PostgreSQL y en casi todos los motores, pero <> es más portable. Los operadores BETWEEN, IN, LIKE y IS NULL se estudian a fondo en el módulo 4.

Cuando mezclas operadores, PostgreSQL los evalúa en este orden (de mayor a menor prioridad):

Lo que más problemas causa es que AND tiene mayor prioridad que OR. Compara:

Traducido a un caso real de TiendaVerde: "quiero los pedidos de Francia o Portugal que estén entregados". Escrito ingenuamente:

La primera versión te devolvería todos los pedidos franceses, entregados o no. No da error: da un resultado incorrecto en silencio, que es mucho peor.

Consejo profesional: aunque te sepas la tabla de precedencia, pon paréntesis siempre que mezcles AND y OR. Cuestan dos caracteres y eliminan la ambigüedad para quien lea tu consulta después.

Un literal es un valor escrito directamente en la sentencia.

Las cadenas van entre comillas simples. Siempre. Este es probablemente el error número uno de quien viene de otros lenguajes de programación, donde "texto" y 'texto' son equivalentes:

El mensaje delata lo que ha pasado: PostgreSQL ha entendido las comillas dobles como un identificador, ha buscado una columna llamada Alimentación y no la ha encontrado.

¿Y si el texto contiene una comilla simple, como en "L'Eliana"? Se duplica:

PostgreSQL también admite las dollar-quoted strings, muy cómodas para textos con muchas comillas:

Los números no llevan comillas. Si escribes '12.50' estás creando una cadena de texto que PostgreSQL a veces convertirá por ti y a veces no, con resultados sorprendentes.

Las fechas se escriben como cadenas de texto, entre comillas simples, en formato ISO 8601 (AAAA-MM-DD):

Escribe siempre en formato ISO. Si escribes '14/02/2026', el motor lo interpretará según su configuración regional (DateStyle), y en un servidor configurado a la americana '03/04/2026' puede significar 3 de abril o 4 de marzo. Es un error que no salta nunca: simplemente produce datos incorrectos. Las funciones de fecha se ven a fondo en el módulo 6.

PostgreSQL acepta varias formas de escribirlos: TRUE/FALSE, 't'/'f', 'yes'/'no', '1'/'0'. Usa TRUE y FALSE a secas: es lo más claro.

Nota de dialecto: MySQL no tiene un tipo booleano real; BOOLEAN es un alias de TINYINT(1) donde TRUE es 1 y FALSE es 0. SQLite tampoco tiene booleano nativo: los guarda como 0 y 1.

NULL no es un valor: es la ausencia de valor. En TiendaVerde, pedidos.empleado_id es NULL cuando el pedido llegó por la web y ningún comercial lo gestionó.

Lo que importa ahora, sintácticamente, es que NULL no se compara con =:

NULL = NULL no da ni verdadero ni falso: da NULL, porque comparar dos incógnitas no permite concluir nada. Por eso existe el operador IS NULL. La semántica completa de los nulos se estudia en la lección 04-03; aquí basta con que retengas la regla: para nulos, IS NULL; nunca = NULL.

Los mensajes de PostgreSQL son de los mejores del sector, pero hay que saber leerlos. Tienen hasta cuatro partes:

La clave está en la expresión "at or near" ("en o cerca de"). PostgreSQL señala dónde detectó el problema, que muy a menudo es una posición después de donde realmente está el error. Si el cursor apunta a algo que parece correcto, mira siempre el token anterior.

Ejemplo real:

El cursor apunta a FROM, pero FROM está perfectamente escrito. El error real es que falta una coma entre nombre y precio: PostgreSQL interpretó precio como un alias de nombre (un alias puede escribirse sin AS), y al llegar a FROM ya no encajaba nada más.

Los errores más frecuentes al empezar y su traducción:

Procedimiento recomendado ante cualquier error:

1. Lee el mensaje entero, no solo la primera palabra.
2. Localiza la línea y la columna con el ^.
3. Si lo señalado parece correcto, mira lo anterior.
4. Comprueba lo básico: comas, paréntesis equilibrados, comillas cerradas, tipo de comilla.
5. Si es un nombre, verifícalo con \d.
6. Si la consulta es larga, redúcela: quita cláusulas hasta que funcione y añádelas de nuevo una a una.

• Usar comillas dobles para texto. "Valencia" es un identificador; 'Valencia' es una cadena. Si el error habla de una "column ... does not exist" con el texto que querías buscar, es esto.
• Olvidar la coma entre columnas. Produce un syntax error at or near "FROM" que despista mucho, porque FROM está bien.
• Crear objetos con "MayúsculasEntrecomilladas". Te condena a repetir las comillas para siempre. Usa snake_case en minúsculas.
• Confiar en la precedencia de AND/OR. No da error, da resultados equivocados. Pon paréntesis.
• División entera inesperada. 10 / 3 es 3. Convierte a decimal antes de calcular porcentajes o medias.
• Fechas en formato local. Escribe siempre 'AAAA-MM-DD'.
• Comparar con = NULL. No devuelve filas nunca, y no avisa. Usa IS NULL.
• Consejo: formatea antes de depurar. Una consulta de una sola línea es imposible de revisar; ponla en varias líneas y el error suele saltar a la vista.
• Consejo: prueba las expresiones con SELECT sin FROM. Antes de meter un cálculo en una consulta grande, verifícalo aislado: SELECT 12.50 * 1.21;.
• Consejo: cuando algo falle, simplifica. Quita mitad de la consulta y comprueba si el error persiste. Es la forma más rápida de acotar.

Localiza y corrige cuatro errores de sintaxis en la siguiente sentencia. Indica qué mensaje daría PostgreSQL en cada caso.

Sin ejecutar nada, predice el resultado de estas cinco expresiones y explica por qué. Después compruébalas con SELECT.

Reescribe esta consulta aplicando las convenciones de estilo del curso (palabras clave en mayúsculas, una cláusula por línea, indentación de las condiciones) y corrige el fallo lógico que contiene: la intención era obtener los pedidos pagados o enviados cuyos gastos de envío superen los 5 €.

Solución 1

Los cuatro errores, en orden de aparición:

Hay además un problema semántico: la tabla productos de TiendaVerde no tiene columna ciudad (esa columna está en clientes y en empleados). PostgreSQL respondería column "ciudad" does not exist. Versión corregida:

Solución 2

Fíjate en el contraste entre las filas 3, 4 y 5: en SQL la insensibilidad a mayúsculas es cosa de la gramática, nunca de los valores, y NULL no se comporta como un valor normal.

Solución 3

El fallo lógico es la precedencia: AND se evalúa antes que OR, de modo que la consulta original significa estado = 'pagado' OR (estado = 'enviado' AND gastos_envio > 5), y devolvería todos los pedidos pagados, incluso los de envío gratuito. Versión corregida y formateada:

Los paréntesis agrupan la alternativa de estados antes de aplicar el filtro de importe. En el módulo 4 verás una forma todavía más legible de escribir esa primera condición: estado IN ('pagado', 'enviado').

Ya conoces las reglas ortográficas del lenguaje:

• Una sentencia se compone de palabras clave, identificadores, literales, operadores y expresiones, organizados en cláusulas y cerrados por ;.
• Las palabras clave no distinguen mayúsculas, pero los identificadores sin comillas se pliegan a minúsculas en PostgreSQL: por eso el curso usa snake_case en minúsculas y evita las comillas dobles.
• Comentas con -- y /* */, y formateas con una cláusula por línea porque el SQL se escribe una vez y se lee muchas.
• Dominas los operadores aritméticos, de comparación y lógicos, y sabes que AND precede a OR: por eso pones paréntesis.
• Distingues los literales: comillas simples para texto y fechas ISO, nada de comillas para números y booleanos, y IS NULL para los nulos.
• Sabes leer un error de PostgreSQL: mensaje, token, línea y cursor, recordando que el fallo suele estar justo antes de lo señalado.

En la siguiente lección, Entendiendo bases de datos y tablas, pasaremos de la forma al contenido: qué es exactamente una base de datos, un esquema, una tabla, una fila y una columna; qué tipos de datos ofrece PostgreSQL y cómo elegir el adecuado (incluido por qué el dinero nunca debe guardarse en un FLOAT); y cómo inspeccionar la estructura de tablas que ya existen.