La entrada de SQL consiste en una secuencia de comandos. Un comando se compone de una secuencia de tokens, terminada por un punto y coma (“;”). El final del flujo de entrada también termina un comando. Qué tokens son válidos depende de la sintaxis del comando en particular.
Un token puede ser una palabra clave, un identificador, un identificador entre comillas, un literal (o constante) o un símbolo de carácter especial. Los tokens normalmente están separados por espacios en blanco (espacio, tabulación, nueva línea), pero no es necesario que lo estén si no hay ambigüedad (que generalmente es el caso solo si un carácter especial está adyacente a algún otro tipo de token).
Por ejemplo, la siguiente es una entrada SQL (sintácticamente) válida:
SELECT * FROM MY_TABLE; UPDATE MY_TABLE SET A = 5; INSERT INTO MY_TABLE VALUES (3, 'hi there');
Esta es una secuencia de tres comandos, uno por línea (aunque esto no es obligatorio; se puede tener más de un comando en una línea, y los comandos se pueden dividir de manera útil en varias líneas).
Además, pueden aparecer comentarios en la entrada SQL. No son tokens, sino que son efectivamente equivalentes a espacios en blanco.
La sintaxis de SQL no es muy consistente con respecto a qué tokens
identifican comandos y cuáles son operandos o parámetros. Los primeros
pocos tokens son generalmente el nombre del comando, por lo que en el ejemplo anterior
normalmente hablaríamos de un comando “SELECT”, un
“UPDATE” y un “INSERT”. Pero
por ejemplo, el comando UPDATE siempre requiere
que aparezca un token SET en una posición determinada, y
esta variación particular de INSERT también
requiere un VALUES para estar completo. Las
reglas de sintaxis precisas para cada comando se describen en la Part VI.
Tokens como SELECT, UPDATE o
VALUES en el ejemplo anterior son ejemplos de
palabras clave, es decir, palabras que tienen un
significado fijo en el lenguaje SQL. Los tokens MY_TABLE
y A son ejemplos de
identificadores. Identifican nombres de
tablas, columnas u otros objetos de la base de datos, según el
comando en el que se utilicen. Por lo tanto, a veces simplemente
se les llama “nombres”. Las palabras clave y los identificadores tienen la
misma estructura léxica, lo que significa que no se puede saber si un
token es un identificador o una palabra clave sin conocer el lenguaje.
Se puede encontrar una lista completa de palabras clave en la Appendix C.
Los identificadores SQL y las palabras clave deben comenzar con una letra
(a-z, pero también letras con
marcas diacríticas y letras no latinas) o un guion bajo
(_). Los caracteres siguientes en un identificador o
palabra clave pueden ser letras, guiones bajos, dígitos
(0-9) o signos de dólar
($). Ten en cuenta que los signos de dólar no están permitidos en los identificadores
según la letra del estándar SQL, por lo que su uso podría hacer que
las aplicaciones sean menos portables.
El estándar SQL no definirá una palabra clave que contenga
dígitos o comience o termine con un guion bajo, por lo que los identificadores de esta
forma están a salvo de posibles conflictos con futuras extensiones del
estándar.
El sistema no utiliza más de NAMEDATALEN-1
bytes de un identificador; se pueden escribir nombres más largos en los
comandos, pero se truncarán. Por defecto,
NAMEDATALEN es 64, por lo que la longitud máxima del identificador
es de 63 bytes. Si este límite resulta problemático, se puede aumentar
cambiando la constante NAMEDATALEN en
src/include/pg_config_manual.h.
Las palabras clave y los identificadores sin comillas no distinguen entre mayúsculas y minúsculas. Por lo tanto:
UPDATE MY_TABLE SET A = 5;
se puede escribir de manera equivalente como:
uPDaTE my_TabLE SeT a = 5;
Una convención que se utiliza a menudo es escribir las palabras clave en mayúsculas y los nombres en minúsculas, por ejemplo:
UPDATE my_table SET a = 5;
Hay un segundo tipo de identificador: el identificador delimitado o identificador entre
comillas. Se forma encerrando una secuencia arbitraria
de caracteres entre comillas dobles
("). Un identificador delimitado
es siempre un identificador, nunca una palabra clave. Por lo tanto,
"select" se podría usar para referirse a una columna o
tabla llamada “select”, mientras que un
select sin comillas se tomaría como una palabra clave y,
por lo tanto, provocaría un error de análisis cuando se use donde se espera un nombre de tabla o
columna. El ejemplo se puede escribir con identificadores entre comillas
así:
UPDATE "my_table" SET "a" = 5;
Los identificadores entre comillas pueden contener cualquier carácter, excepto el carácter con código cero. (Para incluir una comilla doble, escribe dos comillas dobles). Esto permite construir nombres de tablas o columnas que de otro modo no serían posibles, como los que contienen espacios o ampersands. El límite de longitud sigue aplicándose.
Poner un identificador entre comillas también lo hace sensible a mayúsculas y minúsculas, mientras que
los nombres sin comillas siempre se convierten a minúsculas. Por ejemplo, los
identificadores FOO, foo y
"foo" son considerados iguales por
PostgreSQL, pero
"Foo" y "FOO" son
diferentes de estos tres y entre sí. (La conversión de
nombres sin comillas a minúsculas en PostgreSQL es
incompatible con el estándar SQL, que dice que los nombres sin comillas
deben convertirse a mayúsculas. Por lo tanto, foo
debería ser equivalente a "FOO", no a
"foo" según el estándar. Si quieres
escribir aplicaciones portables, se te aconseja que siempre pongas entre comillas un
nombre en particular o que nunca lo hagas).
Una variante de identificadores entre comillas
permite incluir caracteres Unicode escapados identificados
por sus puntos de código. Esta variante comienza
con U& (U en mayúscula o minúscula seguida de
ampersand) inmediatamente antes de las comillas dobles de apertura, sin
espacios de por medio, por ejemplo, U&"foo".
(Ten en cuenta que esto crea una ambigüedad con el
operador &. Usa espacios alrededor del operador para
evitar este problema). Dentro de las comillas, los caracteres Unicode se pueden
especificar en forma escapada escribiendo una barra diagonal inversa seguida del
número de punto de código hexadecimal de cuatro dígitos o, alternativamente, una
barra diagonal inversa seguida de un signo más seguido de un número de punto de código
hexadecimal de seis dígitos. Por ejemplo, el
identificador "data" podría escribirse como
U&"d\0061t\+000061"
El siguiente ejemplo menos trivial escribe la palabra rusa “slon” (elefante) en letras cirílicas:
U&"\0441\043B\043E\043D"
Si se desea un carácter de escape diferente a la barra diagonal inversa, se puede
especificar utilizando
la cláusula UESCAPE
después de la cadena, por ejemplo:
U&"d!0061t!+000061" UESCAPE '!'
El carácter de escape puede ser cualquier carácter individual que no sea un
dígito hexadecimal, el signo más, una comilla simple, una comilla doble
o un carácter de espacio en blanco. Ten en cuenta que el carácter de escape se
escribe entre comillas simples, no comillas dobles,
después de UESCAPE.
Para incluir el carácter de escape en el identificador literalmente, escríbelo dos veces.
Se puede utilizar la forma de escape de 4 o 6 dígitos para especificar pares de sustitutos UTF-16 para componer caracteres con puntos de código mayores que U+FFFF, aunque la disponibilidad de la forma de 6 dígitos hace que esto sea técnicamente innecesario. (Los pares de sustitutos no se almacenan directamente, sino que se combinan en un solo punto de código).
Si la codificación del servidor no es UTF-8, el punto de código Unicode identificado por una de estas secuencias de escape se convierte a la codificación real del servidor; se informa un error si eso no es posible.
Existen tres tipos de constantes de tipo implícito en PostgreSQL: cadenas de caracteres, cadenas de bits y números. Las constantes también se pueden especificar con tipos explícitos, lo que puede permitir una representación más precisa y un manejo más eficiente por parte del sistema. Estas alternativas se discuten en las siguientes subsecciones.
Una constante de cadena de caracteres en SQL es una secuencia arbitraria de caracteres
delimitada por comillas simples ('), por ejemplo,
'Esta es una cadena'. Para incluir
un carácter de comilla simple dentro de una constante de cadena,
escribe dos comillas simples adyacentes, por ejemplo,
'Dianne''s horse'.
Ten en cuenta que esto no es lo mismo que un carácter de
comilla doble (").
Dos constantes de cadena que solo están separadas por espacios en blanco con al menos una nueva línea se concatenan y se tratan efectivamente como si la cadena se hubiera escrito como una sola constante. Por ejemplo:
SELECT 'foo' 'bar';
es equivalente a:
SELECT 'foobar';
pero:
SELECT 'foo' 'bar';
no es una sintaxis válida. (Este comportamiento ligeramente extraño está especificado por SQL; PostgreSQL sigue el estándar).
PostgreSQL también acepta constantes de cadena de
“escape”, que son una extensión del estándar SQL.
Una constante de cadena de escape se especifica escribiendo la letra
E (mayúscula o minúscula) justo antes de la comilla simple de
apertura, por ejemplo, E'foo'. (Al continuar una constante de
cadena de escape a través de líneas, escribe E solo antes de la primera comilla de
apertura).
Dentro de una cadena de escape, un carácter de barra diagonal inversa (\) comienza una
secuencia de escape de barra diagonal inversa similar a C, en la que la combinación
de la barra diagonal inversa y los caracteres siguientes representan un valor de byte especial,
como se muestra en la Table 4.1.
Table 4.1. Secuencias de escape de barra diagonal inversa
| Secuencia de escape de barra diagonal inversa | Interpretación |
|---|---|
\b | retroceso (backspace) |
\f | salto de página (form feed) |
\n | nueva línea (newline) |
\r | retorno de carro (carriage return) |
\t | tabulación (tab) |
\,
\,
\
(o = 0–7)
| valor de byte octal |
\x,
\x
(h = 0–9, A–F)
| valor de byte hexadecimal |
\u,
\U
(x = 0–9, A–F)
| valor de carácter Unicode hexadecimal de 16 o 32 bits |
Cualquier otro
carácter después de una barra diagonal inversa se toma literalmente. Por lo tanto, para
incluir un carácter de barra diagonal inversa, escribe dos barras diagonales inversas (\\).
Además, se puede incluir una comilla simple en una cadena de escape escribiendo
\', además de la forma normal de ''.
Es tu responsabilidad que las secuencias de bytes que crees, especialmente al usar los escapes octales o hexadecimales, compongan caracteres válidos en la codificación del juego de caracteres del servidor. Una alternativa útil es utilizar escapes Unicode o la sintaxis alternativa de escape Unicode, explicada en la Section 4.1.2.3; luego el servidor comprobará que la conversión de caracteres sea posible.
Si el parámetro de configuración
standard_conforming_strings está desactivado (off),
entonces PostgreSQL reconoce los escapes de barra diagonal inversa
tanto en las constantes de cadena normales como en las de escape. Sin embargo, a partir de
PostgreSQL 9.1, el valor por defecto es activado (on), lo que significa
que los escapes de barra diagonal inversa se reconocen solo en las constantes de cadena de escape.
Este comportamiento es más conforme con el estándar, pero podría romper las aplicaciones
que dependen del comportamiento histórico, donde los escapes de barra diagonal inversa
siempre se reconocían. Como solución temporal, puedes establecer este parámetro
en desactivado (off), pero es mejor migrar para evitar el uso de escapes de barra diagonal
inversa. Si necesitas usar un escape de barra diagonal inversa para representar un carácter especial,
escribe la constante de cadena con una E.
Además de standard_conforming_strings, los parámetros de configuración
escape_string_warning y
backslash_quote controlan el tratamiento de las barras diagonales inversas
en las constantes de cadena.
El carácter con el código cero no puede estar en una constante de cadena.
PostgreSQL también admite otro tipo
de sintaxis de escape para cadenas que permite especificar caracteres
Unicode arbitrarios por su punto de código. Una constante de cadena de escape Unicode
comienza con U& (letra U en mayúscula o minúscula
seguida de ampersand) inmediatamente antes de la comilla de apertura, sin
espacios de por medio, por ejemplo, U&'foo'.
(Ten en cuenta que esto crea una ambigüedad con el operador &. Usa espacios
alrededor del operador para evitar este problema). Dentro de las comillas, los
caracteres Unicode se pueden especificar en forma escapada escribiendo una
barra diagonal inversa seguida del número de punto de código hexadecimal de cuatro dígitos
o, alternativamente, una barra diagonal inversa seguida de un signo más
seguido de un número de punto de código hexadecimal de seis dígitos. Por
ejemplo, la cadena 'data' podría escribirse como
U&'d\0061t\+000061'
El siguiente ejemplo menos trivial escribe la palabra rusa “slon” (elefante) en letras cirílicas:
U&'\0441\043B\043E\043D'
Si se desea un carácter de escape diferente al de la barra diagonal inversa, se puede
especificar utilizando la cláusula
UESCAPE
después de la cadena, por ejemplo:
U&'d!0061t!+000061' UESCAPE '!'
El carácter de escape puede ser cualquier carácter individual que no sea un dígito hexadecimal, el signo más, una comilla simple, una comilla doble o un carácter de espacio en blanco.
Para incluir el carácter de escape en la cadena literalmente, escríbelo dos veces.
Se puede utilizar la forma de escape de 4 o 6 dígitos para especificar pares de sustitutos UTF-16 para componer caracteres con puntos de código mayores que U+FFFF, aunque la disponibilidad de la forma de 6 dígitos hace que esto sea técnicamente innecesario. (Los pares de sustitutos no se almacenan directamente, sino que se combinan en un solo punto de código).
Si la codificación del servidor no es UTF-8, el punto de código Unicode identificado por una de estas secuencias de escape se convierte a la codificación real del servidor; se informa un error si eso no es posible.
Además, la sintaxis de escape Unicode para constantes de cadena solo funciona cuando el parámetro de configuración standard_conforming_strings está activado. Esto se debe a que, de lo contrario, esta sintaxis podría confundir a los clientes que analizan las sentencias SQL hasta el punto de que podría conducir a inyecciones SQL y problemas de seguridad similares. Si el parámetro está desactivado, esta sintaxis será rechazada con un mensaje de error.
Si bien la sintaxis estándar para especificar constantes de cadena suele ser
conveniente, puede ser difícil de entender cuando la cadena deseada
contiene muchas comillas simples, ya que cada una de ellas debe
duplicarse. Para permitir consultas más legibles en tales situaciones,
PostgreSQL proporciona otra forma, llamada
“dollar quoting” (delimitación por dólar), para escribir constantes de cadena.
Una constante de cadena delimitada por dólar
consiste en un signo de dólar ($), una
“etiqueta” opcional de cero o más caracteres, otro signo de dólar,
una secuencia arbitraria de caracteres que compone el contenido de la cadena,
un signo de dólar, la misma etiqueta que comenzó esta delimitación
por dólar y un signo de dólar. Por ejemplo, aquí hay dos formas
diferentes de especificar la cadena “Dianne's horse”
utilizando la delimitación por dólar:
$$Dianne's horse$$ $SomeTag$Dianne's horse$SomeTag$
Ten en cuenta que dentro de la cadena delimitada por dólar, se pueden usar comillas simples sin necesidad de escaparlas. De hecho, ningún carácter dentro de una cadena delimitada por dólar se escapa jamás: el contenido de la cadena siempre se escribe literalmente. Las barras diagonales internas no son especiales, ni tampoco los signos de dólar, a menos que formen parte de una secuencia que coincida con la etiqueta de apertura.
Es posible anidar constantes de cadena delimitadas por dólar eligiendo etiquetas diferentes en cada nivel de anidamiento. Esto se usa más comúnmente al escribir definiciones de funciones. Por ejemplo:
$function$
BEGIN
RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$
Aquí, la secuencia $q$[\t\r\n\v\\]$q$ representa una
cadena literal delimitada por dólar [\t\r\n\v\\], que será
reconocida cuando el cuerpo de la función sea ejecutado por
PostgreSQL. Pero dado que la secuencia no coincide
con el delimitador de dólar externo $function$, son solo
algunos caracteres más dentro de la constante en lo que respecta a la cadena
externa.
La etiqueta, si la hay, de una cadena delimitada por dólar sigue las mismas reglas
que un identificador sin comillas, excepto que no puede contener un signo de dólar.
Las etiquetas distinguen entre mayúsculas y minúsculas, por lo que $tag$Contenido de la cadena$tag$
es correcto, pero $TAG$Contenido de la cadena$tag$ no lo es.
Una cadena delimitada por dólar que sigue a una palabra clave o identificador debe estar separada de este por un espacio en blanco; de lo contrario, el delimitador de dólar se tomaría como parte del identificador precedente.
La delimitación por dólar no es parte del estándar SQL, pero a menudo es una forma más conveniente de escribir literales de cadena complicados que la sintaxis de comillas simples conforme al estándar. Es particularmente útil cuando se representan constantes de cadena dentro de otras constantes, como se necesita a menudo en las definiciones de funciones procedimentales. Con la sintaxis de comillas simples, cada barra diagonal inversa en el ejemplo anterior tendría que escribirse como cuatro barras diagonales internas, que se reducirían a dos barras diagonales internas al analizar la constante de cadena original, y luego a una cuando la constante de cadena interna se vuelve a analizar durante la ejecución de la función.
Las constantes de cadena de bits se parecen a las constantes de cadena normales con una
B (mayúscula o minúscula) inmediatamente antes de la comilla
de apertura (sin espacio en blanco de por medio), por ejemplo,
B'1001'. Los únicos caracteres permitidos dentro de
las constantes de cadena de bits son 0 y
1.
Alternativamente, las constantes de cadena de bits se pueden especificar en notación
hexadecimal, usando una X inicial (mayúscula o minúscula),
por ejemplo, X'1FF'. Esta notación es equivalente a
una constante de cadena de bits con cuatro dígitos binarios por cada dígito hexadecimal.
Ambas formas de constantes de cadena de bits se pueden continuar a través de líneas de la misma manera que las constantes de cadena normales. La delimitación por dólar no se puede utilizar en una constante de cadena de bits.
Las constantes numéricas se aceptan en estas formas generales:
dígitosdígitos.[dígitos][e[+-]dígitos] [dígitos].dígitos[e[+-]dígitos]dígitose[+-]dígitos
donde dígitos es uno o más dígitos decimales
(0 al 9). Al menos un dígito debe estar antes o después del punto
decimal, si se utiliza uno. Al menos un dígito debe seguir al marcador de
exponente (e), si hay uno presente. No puede haber
ningún espacio ni otros caracteres incrustados en la constante, excepto
por los guiones bajos, que se pueden utilizar para la agrupación visual como se
describe a continuación. Ten en cuenta que cualquier signo más o menos inicial no se
considera realmente parte de la constante; es un operador aplicado a la
constante.
Estos son algunos ejemplos de constantes numéricas válidas:
42
3.5
4.
.001
5e2
1.925e-3
Además, las constantes enteras no decimales se aceptan en estas formas:
0xdígitos_hex0odígitos_oct0bdígitos_bin
donde dígitos_hex es uno o más dígitos hexadecimales
(0-9, A-F), dígitos_oct es uno o más dígitos
octales (0-7), y dígitos_bin es uno o más dígitos binarios
(0 o 1). Los dígitos hexadecimales y los prefijos de base pueden estar en
mayúsculas o minúsculas. Ten en cuenta que solo los enteros pueden tener formas no decimales,
no los números con partes fraccionarias.
Estos son algunos ejemplos de constantes enteras no decimales válidas:
0b100101
0B10011001
0o273
0O755
0x42f
0XFFFF
Para la agrupación visual, se pueden insertar guiones bajos entre los dígitos. Estos no tienen ningún efecto adicional sobre el valor de la constante. Por ejemplo:
1_500_000_000
0b10001000_00000000
0o_1_755
0xFFFF_FFFF
1.618_034
No se permiten guiones bajos al principio o al final de una constante numérica o de un grupo de dígitos (es decir, inmediatamente antes o después del punto decimal o del marcador de exponente), y no se permite más de un guion bajo seguido.
Una constante numérica que no contiene un punto decimal ni un
exponente se presume inicialmente que es de tipo integer si su
valor cabe en el tipo integer (32 bits); de lo contrario, se presume
que es de tipo bigint si su valor cabe en el tipo
bigint (64 bits); de lo contrario, se toma como de tipo
numeric. Las constantes que contienen puntos decimales y/o
exponentes siempre se presumen inicialmente que son de tipo numeric.
El tipo de datos asignado inicialmente a una constante numérica es solo un
punto de partida para los algoritmos de resolución de tipos. En la mayoría de los casos,
la constante se convertirá automáticamente al tipo más adecuado según
el contexto. Cuando sea necesario, se puede forzar que un valor numérico se
interprete como un tipo de datos específico mediante una conversión (cast).
Por ejemplo, puedes forzar que un valor numérico se trate como tipo
real (float4) escribiendo:
REAL '1.23' -- estilo cadena 1.23::REAL -- estilo PostgreSQL (histórico)
Estos son en realidad solo casos especiales de las notaciones generales de conversión que se discuten a continuación.
Una constante de un tipo arbitrario se puede introducir utilizando cualquiera de las siguientes notaciones:
tipo'cadena' 'cadena'::tipoCAST ( 'cadena' AStipo)
El texto de la constante de cadena se pasa a la rutina de conversión de entrada
para el tipo llamado tipo. El resultado es una constante
del tipo indicado. La conversión de tipo explícita se puede omitir si no hay
ambigüedad en cuanto al tipo que debe tener la constante (por ejemplo, cuando
se asigna directamente a una columna de tabla), en cuyo caso se convierte
automáticamente.
La constante de cadena se puede escribir utilizando la notación SQL regular o delimitada por dólar (dollar-quoting).
También es posible especificar una coerción de tipo usando una sintaxis similar a la de una función:
typename( 'string' )
pero no todos los nombres de tipo se pueden usar de esta manera; consulta Section 4.2.9 para más detalles.
Las sintaxis ::, CAST() y
de llamada a función también se pueden usar para especificar conversiones de tipo en tiempo de ejecución
de expresiones arbitrarias, como se discute en la Section 4.2.9. Para evitar la ambigüedad sintáctica, la
sintaxis tipo 'cadena'tipo 'cadena'::
o CAST() para especificar el tipo de una constante de matriz.
La sintaxis CAST() cumple con SQL. La sintaxis
tipo 'cadena'
Un nombre de operador es una secuencia de hasta NAMEDATALEN-1
(63 por defecto) caracteres de la siguiente lista:
+ - * / < > = ~ ! @ # % ^ & | ` ?
Sin embargo, existen algunas restricciones en los nombres de operadores:
-- y /* no pueden aparecer
en ningún lugar de un nombre de operador, ya que se tomarían como el
inicio de un comentario.
Un nombre de operador de varios caracteres no puede terminar en + o -,
a menos que el nombre también contenga al menos uno de estos caracteres:
~ ! @ # % ^ & | ` ?
Por ejemplo, @- es un nombre de operador permitido,
pero *- no lo es. Esta restricción permite a
PostgreSQL analizar consultas compatibles con SQL
sin requerir espacios entre tokens.
Cuando trabajes con nombres de operadores que no pertenecen al estándar SQL, por lo general
necesitarás separar los operadores adyacentes con espacios para evitar la ambigüedad.
Por ejemplo, si has definido un operador de prefijo llamado @,
no puedes escribir X*@Y; debes escribir
X* @Y para asegurarte de que
PostgreSQL lo lea como dos nombres de operadores
y no como uno solo.
Algunos caracteres que no son alfanuméricos tienen un significado especial que es diferente al de ser un operador. Los detalles sobre su uso se pueden encontrar en el lugar donde se describe el elemento sintáctico respectivo. Esta sección solo existe para advertir sobre la existencia y resumir los propósitos de estos caracteres.
Un signo de dólar ($) seguido de dígitos se utiliza
para representar un parámetro posicional en el cuerpo de una definición de
función o en una sentencia preparada. En otros contextos, el
signo de dólar puede ser parte de un identificador o de una constante de cadena
delimitada por dólar (dollar-quoted).
Los paréntesis (()) tienen su significado habitual para
agrupar expresiones y forzar la precedencia. En algunos casos, los
paréntesis son obligatorios como parte de la sintaxis fija de un
comando SQL en particular.
Los corchetes ([]) se utilizan para seleccionar los elementos
de una matriz (array). Consulta la Section 8.15 para más información
sobre matrices.
Las comas (,) se utilizan en algunas construcciones sintácticas
para separar los elementos de una lista.
El punto y coma (;) termina un comando SQL.
No puede aparecer en ningún lugar dentro de un comando, excepto dentro de una
constante de cadena o un identificador entre comillas.
Dos puntos (:) se utilizan para seleccionar
“rebanadas” (slices) de matrices. (Consulta la Section 8.15). En ciertos dialectos de SQL (como Embedded
SQL), los dos puntos se utilizan para prefijar nombres de variables.
El asterisco (*) se utiliza en algunos contextos para denotar
todos los campos de una fila de tabla o un valor compuesto. También
tiene un significado especial cuando se utiliza como argumento de una
función de agregación, a saber, que el agregado no requiere
ningún parámetro explícito.
El punto (.) se utiliza en constantes
numéricas y para separar nombres de esquemas, tablas y columnas.
Un comentario es una secuencia de caracteres que comienza con dos guiones y se extiende hasta el final de la línea, por ejemplo:
-- Este es un comentario estándar de SQL
Alternativamente, se pueden usar comentarios de bloque estilo C:
/* comentario multilínea * con anidamiento: /* comentario de bloque anidado */ */
donde el comentario comienza con /* y se extiende hasta
la aparición correspondiente de */. Estos comentarios de bloque
se anidan, tal como se especifica en el estándar SQL pero a diferencia de C, de modo que uno puede
comentar bloques más grandes de código que podrían contener comentarios de bloque existentes.
Un comentario se elimina del flujo de entrada antes del análisis sintáctico posterior y se reemplaza efectivamente por un espacio en blanco.
La Table 4.2 muestra la precedencia y asociatividad de los operadores en PostgreSQL. La mayoría de los operadores tienen la misma precedencia y son asociativos por la izquierda. La precedencia y asociatividad de los operadores está integrada de forma rígida en el analizador. Añade paréntesis si quieres que una expresión con múltiples operadores se analice de otra forma que la que implican las reglas de precedencia.
Table 4.2. Precedencia de operadores (de mayor a menor)
| Operador/Elemento | Asociatividad | Descripción |
|---|---|---|
. | izq | separador de nombres de tabla/columna |
:: | izq | conversión de tipo estilo PostgreSQL |
[ ] | izq | selección de elementos de matriz |
+ - | der | más unario, menos unario |
COLLATE | izq | selección de ordenación (collation) |
AT | izq | AT TIME ZONE, AT LOCAL |
^ | izq | exponenciación |
* / % | izq | multiplicación, división, módulo |
+ - | izq | suma, resta |
| (cualquier otro operador) | izq | todos los demás operadores nativos y definidos por el usuario |
BETWEEN IN LIKE ILIKE SIMILAR | contención de rango, pertenencia a conjunto, coincidencia de cadenas | |
< > = <= >= <>
| operadores de comparación | |
IS ISNULL NOTNULL | IS TRUE, IS FALSE, IS
NULL, IS DISTINCT FROM, etc. | |
NOT | der | negación lógica |
AND | izq | conjunción lógica |
OR | izq | disyunción lógica |
Ten en cuenta que las reglas de precedencia de operadores también se aplican a los operadores definidos por el usuario que tienen los mismos nombres que los operadores integrados mencionados anteriormente. Por ejemplo, si defines un operador “+” para algún tipo de datos personalizado, tendrá la misma precedencia que el operador “+” integrado, sin importar lo que haga el tuyo.
Cuando se utiliza un nombre de operador calificado por esquema en la
sintaxis OPERATOR, como por ejemplo en:
SELECT 3 OPERATOR(pg_catalog.+) 4;
se toma que la construcción OPERATOR tiene la precedencia por defecto
mostrada en la Table 4.2 para
“cualquier otro operador”. Esto es cierto sin importar
qué operador específico aparezca dentro de OPERATOR().
Las versiones de PostgreSQL anteriores a la 9.5 utilizaban reglas de precedencia de
operadores ligeramente diferentes. En particular, <=
>= y <> solían tratarse como
operadores genéricos; las pruebas IS solían tener mayor prioridad;
y las construcciones NOT BETWEEN y relacionadas actuaban de manera inconsistente,
tomándose en algunos casos como si tuvieran la precedencia de NOT
en lugar de BETWEEN. Estas reglas se cambiaron para una mejor
conformidad con el estándar SQL y para reducir la confusión de la
diferencia de tratamiento de construcciones lógicamente equivalentes. En la mayoría de los
casos, estos cambios no darán lugar a ningún cambio de comportamiento, o tal vez
a fallos del tipo “no existe tal operador” que se pueden resolver añadiendo
paréntesis. Sin embargo, hay casos límite en los que una consulta podría
cambiar de comportamiento sin que se informe de ningún error de análisis.