Uma entrada SQL consiste em uma sequência de comandos. Um comando é formado por uma sequência de tokens [14] terminada por um ponto-e-vírgula (“;”). O fim do fluxo de entrada também termina o comando. Quais tokens são válidos depende da sintaxe particular de cada comando.
Um token pode ser uma palavra-chave, um identificador, um identificador entre aspas [15], um literal (ou constante) [16] ou um caractere especial. Normalmente os tokens são separados por espaço em branco (espaço, tabulação ou nova-linha), mas não há necessidade caso não haja ambiguidade (o que geralmente só acontece quando um caractere especial está adjacente a outro tipo de token).
Por exemplo, o que vem a seguir é válido (sintaticamente) para uma entrada SQL:
SELECT * FROM MINHA_TABELA; UPDATE MINHA_TABELA SET A = 5; INSERT INTO MINHA_TABELA VALUES (3, 'oi você');
Esta é uma sequência de três comandos, um por linha (embora isso não seja requerido, podendo haver mais de um comando na mesma linha, mesmo assim pode ser útil dividir um comando em várias linhas).
Além disso, as entradas SQL podem conter comentários. Eles não são tokens, na verdade, são equivalentes a espaço em branco.
A sintaxe do SQL não é muito consistente em relação
a quais tokens identificam comandos, e
quais são operandos ou parâmetros.
Os primeiros tokens são geralmente
o nome do comando; portanto, no exemplo mostrado acima, pode-se
dizer que estão presentes os comandos “SELECT”,
“UPDATE” e “INSERT”. Mas, por exemplo, o
comando UPDATE sempre requer que um
token SET apareça em
uma determinada posição, e essa forma particular do comando
INSERT também requer a presença de
VALUES para estar completa.
As regras precisas da sintaxe de cada comando estão descritas na
Parte VI.
Tokens tais como
SELECT, UPDATE, ou VALUES
no exemplo acima são exemplos de palavras-chave,
ou seja, palavras que têm um significado fixo na linguagem
SQL. Os tokens
MINHA_TABELA e A são exemplos de
identificadores
[17].
Eles identificam nomes de tabelas, colunas ou de outros objetos
do banco de dados, dependendo do comando em que são usados.
Portanto, algumas vezes são chamados apenas de “nomes”.
Palavras-chave são identificadores que possuem a mesma estrutura
léxica, significando não ser possível saber se o
token é um identificador ou uma
palavra-chave, sem conhecer a linguagem.
A relação completa das palavras-chave pode ser encontrada no
Apêndice C.
Os identificadores e as palavras-chave do SQL
devem iniciar por uma letra (a-z
e, também, letras com diacrítico
[18]
[19]
- áõç... - e letras não latinas) ou o caractere
sublinhado (_). Os caracteres subsequentes de um
identificador, ou da palavra-chave, podem ser letras, sublinhados,
dígitos (0-9) ou o cifrão
($). Note que, segundo o
padrão SQL, o cifrão não é permitido em
identificadores; portanto, seu uso pode tornar a aplicação menos
portável. O padrão SQL não irá definir
palavras-chave contendo dígitos, ou começando, ou terminando, por
sublinhado, portanto os identificadores com essa forma estão a
salvo contra possíveis conflitos com extensões futuras do padrão.
O sistema não utiliza mais que NAMEDATALEN-1
bytes do identificador; podem ser escritos nomes mais longos nos
comandos, mas são truncados.
Por padrão, NAMEDATALEN é igual a 64; portanto,
o comprimento máximo do identificador é de 63 bytes.
Se esse limite causar problema, pode ser aumentado modificando a
constante NAMEDATALEN no arquivo
src/include/pg_config_manual.h.
Palavras-chave e identificadores sem aspas não fazem distinção entre letras maiúsculas e minúsculas. Portanto:
UPDATE MINHA_TABELA SET A = 5;
pode ser escrito de forma equivalente como:
uPDaTE minha_TaBela SeT a = 5;
Uma convenção comumente usada é escrever as palavras-chave em maiúsculas e os nomes em minúsculas, como mostrado abaixo:
UPDATE minha_tabela SET a = 5;
Existe um segundo tipo de identificador: o
identificador delimitado, ou
identificador entre aspas, formado pela
colocação de uma sequência arbitrária de caracteres entre aspas
(").
Um identificador delimitado é sempre um identificador, e nunca uma
palavra-chave. Portanto, "select" pode ser usado
para fazer referência a uma coluna ou tabela chamada "select",
enquanto select sem aspas é sempre uma
palavra-chave, ocasionando, por isso, erro do analisador quando
usada onde é esperado um nome de tabela ou de coluna.
O exemplo acima pode ser reescrito utilizando identificadores entre
aspas, como mostrado abaixo:
UPDATE "minha_tabela" SET "a" = 5;
Identificadores entre aspas podem conter qualquer caractere que não seja a própria aspa (Para incluir uma aspa, devem ser escritas duas aspas). Isso permite criar nomes de tabelas e de colunas que não seriam possíveis de outra forma, como os contendo espaços ou e-comercial (&). O limite do comprimento ainda se aplica.
Envolver um identificador por aspas torna-o sensível a maiúsculas
e minúsculas, enquanto os nomes não envoltos por aspas são
sempre convertidas para minúsculas. Por exemplo, os identificadores
FOO, foo e
"foo" são considerados o mesmo identificador pelo
PostgreSQL, mas "Foo"
e "FOO" são diferentes dos três primeiros, e
entre si.
(A conversão dos nomes que não estão entre aspas em minúsculas no
PostgreSQL é incompatível com o padrão
SQL, que define que os nomes não envoltos por
aspas devem ser convertidos para maiúsculas.
Portanto, foo deveria ser equivalente a
"FOO", e não a "foo",
segundo o padrão. Se for desejado escrever aplicações portáveis,
é recomendável colocar um determinado nome sempre entre aspas,
ou nunca o colocar entre aspas.)
Uma forma alternativa de identificadores entre aspas permite incluir
caracteres Unicode com escape identificados por seus pontos de
código.
[20]
Esta forma alternativa começa por U&
(U maiúsculo ou minúsculo seguido por e-comercial) logo
antes da aspa de abertura, sem espaços entre eles, por exemplo,
U&"foo".
(Note que isso cria uma ambiguidade com o operador
&. Devem ser colocados espaços em torno do
operador para evitar esse problema.)
Dentro das aspas, os caracteres
Unicode podem ser especificados em forma de escape, escrevendo uma
contrabarra (\) seguida pelo número de ponto de
código hexadecimal de quatro dígitos ou, como alternativa, uma
contrabarra seguida por um sinal de mais seguido por um número de
ponto de código hexadecimal de seis dígitos. Por exemplo, o
identificador "data" pode ser escrito como:
U&"d\0061t\+000061"
O seguinte exemplo, menos trivial, escreve a palavra russa “slon” (elefante) no alfabeto cirílico:
U&"\0441\043B\043E\043D"
Se for desejado usar um caractere de escape diferente da contrabarra,
esse pode ser especificado usando a cláusula
UESCAPE
após a cadeia de caracteres. Por exemplo:
U&"d!0061t!+000061" UESCAPE '!'
O caractere de escape pode ser qualquer caractere que não seja um
dígito hexadecimal, o sinal de mais, aspas, apóstrofos, ou um
caractere de espaço em branco. Note que o caractere de escape é
escrito entre apóstrofos ('), e não entre aspas
("), após UESCAPE.
Para incluir o caractere de escape no identificador sem interpretação, escreva-o duas vezes.
Tanto a forma de escape de 4 dígitos quanto a de 6 dígitos podem ser usadas para especificar pares substitutos [21] UTF-16, compondo assim caracteres com pontos de código maiores que U+FFFF, embora a disponibilidade da forma de 6 dígitos tecnicamente torne isso desnecessário. (Os pares substitutos não são armazenados diretamente, mas são combinados em um único ponto de código.)
Se a codificação do servidor não for UTF-8, o ponto de código Unicode identificado por uma destas sequências de escape será convertido na codificação do servidor em atividade; será relatado um erro se isso não for possível.
Existem três tipos de constante com tipo implícito no PostgreSQL: cadeias de caracteres, cadeias de bits e números. As constantes também podem ser definidas com tipo explícito, permitindo uma representação mais precisa e um tratamento mais eficiente por parte do sistema. Essas alternativas estão discutidas nas próximas subseções.
Uma constante do tipo cadeia de caracteres no SQL
é uma sequência arbitrária de caracteres entre apóstrofos
(') como, por exemplo,
'Essa é uma cadeia de caracteres'. Para incluir um apóstrofo dentro
da constante do tipo cadeia de caracteres, devem ser escritos dois
apóstrofos adjacentes como, por exemplo,
'Maria D''Almeida'.
Note que esse não é o mesmo caractere aspas
(")
usado nos identificadores delimitados.
Duas constantes do tipo cadeia de caracteres separadas apenas por espaços em branco com pelo menos um caractere de nova-linha, são concatenadas e tratadas de fato como se toda a cadeia de caracteres tivesse sido escrita em uma única constante. Por exemplo:
SELECT 'foo' 'bar';
equivale a:
SELECT 'foobar';
mas:
SELECT 'foo' 'bar';
não é uma sintaxe válida (esse comportamento, um tanto ao quanto estranho, é especificado pelo padrão SQL; o PostgreSQL está seguindo o padrão).
O PostgreSQL também aceita constantes
cadeias de caracteres utilizando “escape”, que é uma
extensão do padrão SQL. Uma constante cadeia de
caracteres com escape é definida escrevendo a letra
E (maiúscula ou minúscula) logo antes do apóstrofo
de abertura, por exemplo, E'foo'. (Ao continuar uma constante cadeia
de caracteres com escape em outra linha, escreva E
somente antes do primeiro apóstrofo de abertura.)
Dentro da cadeia de caracteres com escape, um caractere de
contrabarra (\) inicia um
escape de contrabarra estilo-C, onde a
combinação da contrabarra com o(s) caractere(s) seguinte(s)
representam um valor de byte especial, conforme mostrado na
Tabela 4.1.
[22]
Tabela 4.1. Sequências de escape de contrabarra
| Sequência de escape de contrabarra | Interpretação |
|---|---|
\b | retrocesso (backspace) |
\f | avanço de formulário (form feed) |
\n | nova linha (newline) |
\r | retorno de carro (carriage return) |
\t | tabulação (tab) |
\,
\,
\
(o = 0–7)
| valor do byte em notação octal |
\x,
\x
(h = 0–9, A–F)
| valor do byte em notação hexadecimal |
\u,
\U
(x = 0–9, A–F)
| caractere Unicode em notação hexadecimal de 16 ou 32-bits |
Qualquer outro caractere após a contrabarra é tomado literalmente.
Portanto, para incluir um caractere de contrabarra, devem ser
escritas duas contrabarras (\\).
Também pode ser incluído o apóstrofo na cadeia de caracteres com
escape escrevendo-se \', além da maneira normal
''. Exemplo:
[23]
SELECT E'a\nc' AS "Nova linha",
E'a\bc' AS "Backspace",
E'a\'c' AS "Apóstrofo 1",
E'a''c' AS "Apóstrofo 2",
E'a\\c' AS "Contrabarra";
Nova linha | Backspace | Apóstrofo 1 | Apóstrofo 2 | Contrabarra
------------+-----------+-------------+-------------+-------------
a +| a\x08c | a'c | a'c | a\c
c | | | |
(1 linha)
É de sua responsabilidade que as sequências de bytes que você cria, principalmente quando você usa escapes octais ou hexadecimais, que essas sequências tenham caracteres válidos na codificação do conjunto de caracteres do servidor. Uma alternativa útil é usar escapes Unicode, ou a sintaxe alternativa de escape Unicode, explicada em Constantes do tipo cadeia de caracteres com escapes Unicode; dessa maneira o servidor irá verificar se a conversão de caracteres é possível.
Se o parâmetro de configuração
standard_conforming_strings estiver desativado
(off), o PostgreSQL
reconhecerá escapes de contrabarra em constantes cadeias de
caracteres regular e de escape. No entanto, a partir do
PostgreSQL 9.1, o padrão passou a ser ativado
(on), significando que os escapes de contrabarra
são reconhecidos apenas em constantes do tipo cadeia de caracteres de escape.
Esse comportamento é mais próximo do padrão SQL,
mas pode causar problemas em aplicações que dependem do comportamento
histórico, onde os escapes de contrabarra sempre foram reconhecidos.
Como solução alternativa, esse parâmetro pode ser definido como
desativado, mas é preferível não usar escapes de contrabarra.
Se for necessário usar escape de contrabarra para representar um
caractere especial, a constante do tipo cadeia de caracteres deve
ser escrita com um E na frente.
Além do standard_conforming_strings, os parâmetros
de configuração escape_string_warning e
backslash_quote controlam o tratamento das
contrabarras em constantes do tipo cadeia de caracteres.
O caractere com o código zero não pode estar presente em uma constante do tipo cadeia de caracteres de escape. Exemplo: [24]
SELECT E'A\x00B';
ERRO: sequência de bytes é inválida para codificação "UTF8": 0x00
O PostgreSQL também aceita outro tipo
de sintaxe de escape para cadeias de caracteres, que permite
especificar caracteres Unicode arbitrários por ponto de código.
Uma constante do tipo cadeia de caracteres de escape Unicode começa
por U& (letra maiúscula ou minúscula U,
seguida por e-comercial) logo antes do apóstrofo de
abertura, sem espaços entre eles, por exemplo, U&'foo'.
(Note que isso cria uma ambiguidade com o operador
&. Use espaços em torno do operador para
evitar esse problema.) Dentro dos apóstrofos, os caracteres Unicode
podem ser especificados em forma de escape escrevendo uma contrabarra
seguida pelo número de ponto de código hexadecimal de quatro dígitos
ou, como alternativa, uma contrabarra seguida por um sinal de mais
(+), seguido por um número de ponto de código
hexadecimal de seis dígitos. Por exemplo, a cadeia de caracteres
'data' pode ser escrita como:
U&'d\0061t\+000061'
O seguinte exemplo, menos trivial, escreve a palavra russa “slon” (elefante) em letras cirílicas:
U&'\0441\043B\043E\043D'
Se for desejado usar um caractere de escape diferente da contrabarra,
esse pode ser especificado usando a cláusula UESCAPE
após a cadeia de caracteres. Por exemplo:
U&'d!0061t!+000061' UESCAPE '!'
O caractere de escape pode ser qualquer caractere que não seja um
dígito hexadecimal, o sinal de mais, aspas, apóstrofos, ou um
caractere de espaço em branco. Note que tudo é escrito entre
apóstrofos (')
Para incluir o caractere de escape na cadeia de caracteres sem interpretação, esse deve ser escrito duas vezes.
Tanto a forma de escape de 4 dígitos, quanto a de 6 dígitos, podem ser usadas para especificar pares substitutos UTF-16, compondo assim caracteres com pontos de código maiores que U+FFFF, embora a disponibilidade da forma de 6 dígitos tecnicamente torne isso desnecessário. (Os pares substitutos não são armazenados diretamente, mas são combinados em um único ponto de código.)
Se a codificação do servidor não for UTF-8, o ponto de código Unicode identificado por uma dessas sequências de escape será convertido na codificação do servidor em atividade; um erro é relatado se isso não for possível.
Além disso, a sintaxe de escape Unicode para constantes cadeia
de caracteres só funciona quando o parâmetro de configuração
standard_conforming_strings está ativo
(on).
Isso acontece, porque, caso contrário, essa sintaxe pode confundir os
clientes que analisam as instruções SQL a ponto de levar a injeções
de SQL e problemas de segurança semelhantes.
Se o parâmetro estiver desativado, essa sintaxe será rejeitada com
uma mensagem de erro.
Exemplo: [25]
SELECT U&'d\0061t\+000061' AS "DATA U4+U4",
U&'\0441\043B\043E\043D' AS "ELEFANTE",
U&'d!0061t!+000061' UESCAPE '!' AS "DATA U4+U6";
DATA U4+U4 | ELEFANTE | DATA U4+U6
------------+----------+------------
data | слон | data
(1 linha)
Embora a sintaxe padrão para definir constantes cadeia de caracteres seja geralmente conveniente, pode ser difícil ser entendida quando a cadeia de caracteres desejada contém muitos apóstrofos, porque cada um deles deve ser duplicado. Para permitir consultas mais legíveis nessas situações, o PostgreSQL fornece outra maneira, chamada “delimitação por cifrão”, para escrever constantes cadeia de caracteres. Uma constante do tipo cadeia de caracteres delimitada por cifrão consiste em um cifrão ($), uma “etiqueta” opcional de zero ou mais caracteres, outro cifrão, a sequência arbitrária de caracteres que compõe o conteúdo da cadeia de caracteres, um cifrão, a mesma etiqueta que começou essa delimitação, e um cifrão. Por exemplo, aqui estão duas maneiras diferentes para definir a cadeia de caracteres “Maria D'Almeida” usando delimitação por cifrão:
$$Maria D'Almeida$$ $Etiqueta$Maria D'Almeida$Etiqueta$
Note que dentro da cadeia de caracteres delimitada por cifrão, os apóstrofos podem ser usados sem a necessidade de escape. De fato, nenhum caractere dentro da cadeia de caracteres delimitada por cifrão precisa de escape: o conteúdo da cadeia de caracteres é sempre escrito literalmente. As contrabarras não são caracteres especiais, nem os cifrões, a menos que façam parte de uma sequência que corresponda à etiqueta de abertura.
É possível aninhar constantes cadeias de caractere delimitadas por cifrão usando etiquetas diferentes para cada nível de aninhamento. Isso é geralmente usado ao escrever definições de função. Por exemplo:
$function$
BEGIN
RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$
Nesse exemplo, a sequência $q$[\t\r\n\v\\]$q$
representa a cadeia de caracteres delimitada por cifrão
[\t\r\n\v\\], que será reconhecida quando o
corpo da função for executado pelo
PostgreSQL. Mas como a sequência não
corresponde ao delimitador cifrão externo
$function$, são apenas mais alguns caracteres
dentro da constante no que diz respeito à cadeia de caracteres
externa.
As etiquetas das cadeias de caracteres delimitadas por cifrão,
caso existam, seguem as mesmas regras de um identificador
não delimitado, exceto por não poderem conter o caractere cifrão.
As etiquetas diferenciam letras maiúsculas de minúsculas,
portanto
$etiqueta$Conteúdo da cadeia de caracteres$etiqueta$
está correto, porém
$ETIQUETA$Conteúdo da cadeia de caracteres$etiqueta$
não está.
Uma cadeia de caracteres delimitada por cifrão, que vem após uma palavra-chave ou identificador, deve estar separada deste por espaço em branco; caso contrário, o delimitador de cifrão seria considerado parte do identificador anterior.
A delimitação por cifrão não faz parte do padrão SQL, mas é geralmente uma maneira mais conveniente para escrever constantes cadeias de caractere complicadas, do que a sintaxe de apóstrofos compatível com o padrão. É particularmente útil ao representar constantes cadeias de caracteres dentro de outras constantes, como muitas vezes se faz necessário em definições de funções procedurais. Com a sintaxe de apóstrofos, cada contrabarra no exemplo acima teria que ser escrita com quatro contrabarras, que seriam reduzidas a duas contrabarras ao analisar a constante cadeia de caracteres original e, em seguida, a uma quando a constante do tipo cadeia de caracteres interna for analisada novamente durante a execução da função.
As constantes do tipo cadeia de bits se parecem com uma constante
cadeia de caracteres regular contendo um B
(maiúsculo ou minúsculo) logo antes do apóstrofo de
abertura (sem espaço intermediário), como, por exemplo, em
B'1001'. Os únicos caracteres permitidos dentro
da constante cadeia de bits são 0 e
1.
Como alternativa, as constantes cadeia de bits podem ser
definidas na notação hexadecimal usando um X
(maiúsculo ou minúsculo) inicial, como, por exemplo, em
X'1FF'. Essa notação é equivalente a uma
constante cadeia de bits com quatro dígitos binários para cada
dígito hexadecimal.
Ambas as formas de constante cadeia de bits podem ser continuadas em outras linhas da mesma maneira que as constantes cadeia de caracteres regulares. A delimitação por cifrão não pode ser usada em uma constante cadeia de bits.
Exemplo: [26]
SELECT X'1FF' AS "12 BITS HEXA",
B'000111111111' AS "12 BITS BIN",
X'1FF'::integer - B'000111111111'::integer AS "DIFERENÇA";
12 BITS HEXA | 12 BITS BIN | DIFERENÇA --------------+--------------+----------- 000111111111 | 000111111111 | 0 (1 linha)
São aceitas constantes numéricas nas seguintes formas gerais:
dígitosdígitos.[dígitos][e[+-]dígitos] [dígitos].dígitos[e[+-]dígitos]dígitose[+-]dígitos
onde dígitos são um ou mais dígitos
decimais (0 a 9). Deve haver pelo menos um dígito antes ou depois
do ponto decimal, se esse for usado. Deve haver pelo menos um
dígito após a marca de expoente (e), caso esteja
presente. Não podem existir espaços ou outros caracteres incorporados
à constante, exceto os sublinhados, que podem ser usados para
agrupamento visual, conforme descrito abaixo.
Note que os sinais menos e mais que antecedem a constante não são,
na verdade, considerados parte da constante, e sim um operador
aplicado à constante.
Abaixo são mostrados alguns exemplos de constantes numéricas válidas:
42 3.5 4. .001 5e2 1.925e-3
Além disso, constantes inteiras não decimais são aceitas nos seguintes formatos:
0xdígitos_hexadecimais0odígitos_octais0bdígitos_binários
onde dígitos_hexadecimais é um ou mais
dígito hexadecimal (0-9, A-F),
dígitos_octais é um ou mais dígito octal
(0-7), e dígitos_binários
é um ou mais dígito binário (0 or 1).
Os dígitos hexadecimais e os prefixos de base podem estar em
letras maiúsculas ou minúsculas.
Note que apenas os números inteiros podem incluir uma
parte fracionária.
[27]
Isso não ocorre com os demais números.
Estes são alguns exemplos de constantes inteiras não decimais válidas:
0b100101 0B10011001 0o273 0O755 0x42f 0XFFFF
Para agrupamento visual, podem ser inseridos sublinhados entre os dígitos. Estes sublinhados não têm nenhum efeito adicional sobre o valor da constante. Por exemplo:
1_500_000_000 0b10001000_00000000 0o_1_755 0xFFFF_FFFF 1.618_034
Não são permitidos sublinhados no início ou no final de uma constante numérica ou de um grupo de dígitos (isto é, imediatamente antes ou depois do ponto decimal ou do marcador de expoente), e não é permitido mais de um sublinhado em sequência (juntos).
Uma constante numérica não contendo o ponto decimal nem o expoente
é presumida, inicialmente, como sendo do tipo integer,
se o seu valor for apropriado para o tipo integer
(32 bits); senão é presumida como sendo do tipo bigint,
se o seu valor for apropriado para o tipo bigint
(64 bits); caso contrário, é assumida como sendo do tipo
numeric. As constantes que contêm ponto decimal e/ou
expoentes são sempre presumidas inicialmente como sendo do tipo
numeric.
O tipo de dados atribuído inicialmente para a constante numérica é
apenas o ponto de partida para os algoritmos de resolução de tipo.
Geralmente, a constante é automaticamente convertida no
tipo mais apropriado conforme o contexto. Quando for necessário,
pode-se impor que o valor numérico seja interpretado como sendo de
um tipo de dados específico, fazendo a sua conversão.
Por exemplo, pode-se impor que o valor numérico seja tratado como
sendo do tipo real (float4) escrevendo:
REAL '1.23' -- estilo cadeia de caracteres 1.23::REAL -- estilo PostgreSQL (histórico)
Na verdade, estes são apenas casos especiais das notações gerais de conversão mostradas a seguir.
Pode ser declarada uma constante de um tipo arbitrário utilizando uma das seguintes notações:
tipo'cadeia de caracteres' 'cadeia de caracteres'::tipoCAST ( 'cadeia de caracteres' AStipo)
O texto da constante do tipo cadeia de caracteres é passado para a rotina
de conversão para o tipo chamado tipo.
O resultado é uma constante do tipo indicado. A conversão explícita
de tipo pode ser omitida caso não haja ambiguidade com relação ao
tipo que a constante deva ter (por exemplo, quando é atribuída
diretamente para a coluna de uma tabela), nesse caso é convertida
automaticamente.
A constante do tipo cadeia de caracteres pode ser escrita utilizando tanto a notação regular do padrão SQL, quanto a delimitação por cifrão.
Também é possível definir a conversão de tipo utilizando uma sintaxe semelhante a de chamada de função:
nome_do_tipo( 'cadeia de caracteres' )
mas nem todos os nomes de tipo podem ser usados desta forma. Veja a Seção 4.2.9 para obter mais detalhes.
As sintaxes ::, CAST() e
chamada de função, também podem ser usadas para definir
conversões de tipo de expressões arbitrárias em tempo de execução,
conforme discutido na Seção 4.2.9.
Para evitar ambiguidade sintática, a sintaxe do
tipo
'cadeia de caracteres'tipo
'cadeia de caracteres'array);
deve ser usado :: ou CAST()
para definir o tipo de uma constante em forma de matriz.
A sintaxe CAST() está em conformidade com o
padrão SQL. A sintaxe
tipo
'cadeia de caracteres':: é um uso histórico no
PostgreSQL, assim como a sintaxe de
chamada de função.
Um nome de operador é uma sequência com até
NAMEDATALEN-1 (63, por padrão) caracteres da
seguinte lista:
+ - * / < > = ~ ! @ # % ^ & | ` ?
Entretanto, existem algumas poucas restrições para os nomes de operadores:
-- e /* não podem aparecer
em nenhum lugar no nome do operador, porque são considerados
início de comentário.
Um nome de operador com múltiplos caracteres não pode terminar por
+ ou -,
a não ser que o nome também contenha ao menos um dos seguintes
caracteres:
~ ! @ # % ^ & | ` ?
Por exemplo, @- é um nome de operador permitido,
mas *- não é. Esta restrição permite ao
PostgreSQL analisar comandos
compatíveis com o padrão SQL sem requerer
espaços entre os tokens.
Ao trabalhar com nomes de operadores que não fazem parte do padrão
SQL, normalmente é necessário separar os
operadores adjacentes por espaço, para evitar ambiguidade. Por exemplo,
se for definido um operador unário-esquerdo (prefixo) chamado
@, não poderá ser escrito X*@Y;
deverá ser escrito X* @Y, para garantir que o
PostgreSQL leia dois nomes de operador,
e não apenas um.
Alguns caracteres não alfanuméricos têm um significado especial diferente do significado de um operador. Os detalhes da utilização podem ser encontrados nos locais onde o respectivo elemento de sintaxe está descrito. Essa seção se destina apenas a informar a existência e fazer um resumo das finalidades desses caracteres.
O caractere cifrão ($) seguido por dígitos é
usado para representar parâmetros posicionais no corpo da
definição de uma função ou de uma instrução preparada.
Em outros contextos, o caractere cifrão pode ser parte do
identificador, ou de uma constante do tipo cadeia de caracteres
delimitada por cifrão.
Os parênteses (()) possuem seu significado
habitual de agrupar expressões e impor precedência. Em alguns
casos, os parênteses são requeridos como parte da sintaxe
estabelecida para um determinado comando SQL.
Os colchetes ([]) são usados para selecionar
elementos da matriz. Veja a Seção 8.15 para
obter mais informações sobre matrizes.
As vírgulas (,) são usadas em algumas
construções sintáticas para separar os elementos da lista.
O ponto-e-vírgula (;) termina o comando
SQL, não podendo aparecer em nenhum lugar
dentro do comando, exceto dentro de uma constante cadeia de
caracteres, ou de um identificador entre aspas.
Os dois-pontos (:) são usados para selecionar
“fatias” de matrizes (veja a Seção 8.15).
Em certos dialetos do SQL, como o
SQL Embarcado (Embedded SQL),
os dois-pontos são usados como prefixo dos nomes das variáveis.
O asterisco (*) é usado em alguns contextos
para indicar todos os campos na linha de uma tabela, ou de um
valor composto. Também possui significado especial quando
usado como argumento de uma função de agregação, significando que
a agregação não requer um parâmetro explícito.
O ponto (.) é usado nas constantes numéricas,
e para separar os nomes de esquemas, tabelas e colunas.
Um comentário é uma sequência arbitrária de caracteres começando por dois hifens e se estendendo até o final da linha, como, por exemplo:
-- Este é um comentário em conformidade com o padrão SQL-92
Como alternativa, podem ser usados blocos de comentários no estilo C:
/* comentário de várias linhas * com aninhamento: /* bloco de comentário aninhado */ */
onde o comentário começa por /* e se estende até
encontrar a ocorrência correspondente de */.
Esses blocos de comentários podem estar aninhados, conforme
definido no padrão SQL, mas não como na
linguagem C, permitindo transformar em comentário grandes blocos
de código contendo blocos de comentários.
Os comentários são removidos do fluxo de entrada antes de prosseguir com a análise sintática, sendo substituídos por um espaço em branco.
A Tabela 4.2 mostra a precedência e a associatividade dos operadores no PostgreSQL. A maioria dos operadores possui a mesma precedência e são associativos à esquerda. A precedência e a associatividade dos operadores estão codificadas no analisador. Adicione parênteses se desejar que uma expressão com vários operadores seja analisada de alguma outra maneira, que não seja a que as regras de precedência implicam.
Tabela 4.2. Precedência dos operadores (da mais alta para a mais baixa)
| Operador/Elemento | Associatividade | Descrição |
|---|---|---|
. | esquerda | separador de nome de tabela e coluna |
:: | esquerda | conversão de tipo no estilo PostgreSQL |
[ ] | esquerda | seleção de elemento da matriz |
+ - | direita | mais unário, menos unário |
COLLATE | esquerda | seleção de colação |
AT | esquerda | AT TIME ZONE, AT LOCAL |
^ | esquerda | exponenciação |
* / % | esquerda | multiplicação, divisão, módulo |
+ - | esquerda | adição, subtração |
| (qualquer outro operador) | esquerda | qualquer outro operador nativo ou definido pelo usuário |
BETWEEN IN LIKE ILIKE SIMILAR | contido no intervalo, membro do conjunto, correspondência de padrão em cadeia de caracteres | |
< > = <= >= <> | operadores de comparação | |
IS ISNULL NOTNULL | IS TRUE, IS FALSE, IS
NULL, IS DISTINCT FROM, etc. | |
NOT | direita | negação lógica |
AND | esquerda | conjunção lógica |
OR | esquerda | disjunção lógica |
Note que as regras de precedência do operador também se aplicam aos operadores definidos pelos usuários que possuem os mesmos nomes dos operadores internos mencionados acima. Por exemplo, se for definido pelo usuário um operador “+” para algum tipo de dado personalizado, esse terá a mesma precedência do operador “+” interno, não importando o que faça.
Quando é usado um nome de operador qualificado pelo esquema na
sintaxe OPERATOR como, por exemplo, em
SELECT 3 OPERATOR(pg_catalog.+) 4;
a construção OPERATOR é assumida como tendo a
precedência padrão mostrada na Tabela 4.2
para “qualquer outro operador”. Isso é sempre verdade,
não importando qual o nome do operador definido dentro de
OPERATOR().
As versões do PostgreSQL anteriores a 9.5
usavam regras de precedência de operador ligeiramente diferentes.
Em particular, <= >= e
<> costumavam ser tratados como operadores
genéricos; os testes de IS costumavam ter
prioridade mais alta; e NOT BETWEEN e construções
relacionadas agiam de forma inconsistente, sendo tomadas, em alguns
casos, como tendo a precedência do NOT, em vez
da precedência do BETWEEN. Essas regras foram
alteradas para melhorar a conformidade com o padrão
SQL e para reduzir a confusão do tratamento
inconsistente de construções logicamente equivalentes.
Geralmente, essas mudanças não vão resultar em nenhuma
mudança de comportamento, ou talvez em falhas de
“operador desconhecido” que podem ser resolvidas
adicionando parênteses. No entanto, há casos especiais em que
uma consulta pode mudar seu comportamento sem que nenhum erro de
análise seja relatado.
[14] Token: Uma unidade básica e gramaticalmente indivisível de uma linguagem, como uma palavra-chave, operador ou identificador. FOLDOC - Free On-Line Dictionary Of Computing (N. T.)
[15]
Nesse texto aspas duplas são chamadas apenas
de aspas ("), e
aspas simples são chamadas de
apóstrofos( '). (N. T.)
[16] Uma constante (às vezes chamada de literal) especifica um valor. Constantes são classificadas como constantes de cadeias de caracteres ou constantes numéricas. As constantes numéricas são ainda classificadas como inteiras, de ponto flutuante ou decimais. IBM DB2 Constants (N. T.)
[17] O nome do objeto de banco de dados é conhecido como identificador. Tudo no Microsoft SQL Server pode ter um identificador. Servidores, bancos de dados e objetos de banco de dados, como tabelas, visões, colunas, índices, gatilhos, procedimentos, restrições e regras, podem ter identificadores. Os identificadores são necessários para a maioria dos objetos, mas são opcionais para alguns objetos, como restrições. Identificadores de banco de dados (N. T.)
[18] Diacrítico: Diz-se de ou sinal gráfico que serve para diferenciar letras ou palavras (ex.: sinal diacrítico; os acentos, o til e a cedilha são diacríticos). “diacrítico”, in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2021, [consultado em 03-07-2022]. (N. T.)
[19] Diacrítico: (1) Uma marca aplicada ou anexada a um símbolo para criar um novo símbolo representando o valor modificado ou novo. (2) Uma marca aplicada a um símbolo independentemente de alterar o valor desse símbolo. No último caso, o diacrítico geralmente representa um valor independente (por exemplo, um acento, tom ou alguma outra informação linguística). Também chamado de marca diacrítica ou diacrítico. Glossary of Unicode Terms. (N. T.)
[20] Ponto de código: (1) Qualquer valor no codespace Unicode; ou seja, no intervalo de inteiros de 0 a 10FFFF₁₆. Nem todos os pontos de código são atribuídos a caracteres codificados. Veja tipo de ponto de código. (2) Um valor, ou posição, para um caractere, em qualquer conjunto de caracteres codificados. Code Point (N. T.)
[21] Par substituto (Surrogate pair): Uma representação para um único caractere abstrato que consiste em uma sequência de duas unidades de código de 16 bits, onde o primeiro valor do par é uma unidade de código substituto alto e o segundo valor é uma unidade de código substituto baixo. Surrogates (N. T.)
[22] Veja também: Sequências de escape. (N. T.)
[23] Exemplo escrito pelo tradutor, não fazendo parte da documentação original.
[24] Exemplo escrito pelo tradutor, não fazendo parte da documentação original.
[25] Exemplo escrito pelo tradutor, não fazendo parte da documentação original.
[26] Exemplo escrito pelo tradutor, não fazendo parte da documentação original.