Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Sintassi SQL
PrecedenteIl linguaggio SQLEspressioni di valoreSuccessivo

4. Sintassi SQL

Questo capitolo descrive la sintassi di SQL. Costituisce le fondamenta per la comprensione dei capitoli seguenti che affronteranno in dettaglio come vengono applicati i comandi SQL per definire e modificare i dati.

Si avvisano inoltre gli utenti che sono già familiari con SQL di leggere questo capitolo attentamente perchè contiene diverse regole e concetti che sono implementati in modo incoerente tra i vari database SQL o che sono propriamente specifici di PostgreSQL™.

4.1. Struttura lessicale

Un input SQL consiste in una sequenza di comandi. Un comando è composto da una sequenza di token, terminati da un punto e virgola («;»). La fine del flusso (stream) di input determina anche la conclusione del comando. Quali token siano validi dipende dalla sintassi stessa del particolare comando.

Un token può essere una parola chiave, un identificatore, un identificatore quotato, un letterale (o costante), o un simbolo speciale. I token normalmente sono separati da spazi bianchi (spazio, tab, nuova linea), ma questo non dinventa obbligatorio qualora non ci sia ambiguità (generalmente solo il caso in cui un carattere speciale è adiacente a qualche altro tipo di token).

Per esempio, il seguente input è (sintatticamente) SQL valido:

SELECT * FROM MY_TABLE;
UPDATE MY_TABLE SET A = 5;
INSERT INTO MY_TABLE VALUES (3, 'hi there');

Questa è una sequenza di tre comandi, uno per linea (anche se questo non è richiesto - più di un comando infatti può stare in una linea, e i comandi possono essere distribuiti su più linee).

Inoltre, in un input SQL possono essere inseriti dei commenti. Questi non vengono considerati veri e propri token, ma vengono semplicemente equiparati a uno spazio.

La sintassi SQL non è molto coerente in merito a quali token identificano un comando e quali invece un operatore o un parametro. I primissimi token identificano generalmente il nome del comando. Riprendendo l'esempio di sopra, si tratterebbe quindi di un comando «SELECT», uno «UPDATE» e infine uno «INSERT». Tuttavia, ad esempio, il comando UPDATE richiede che un token SET sia presente in una certa posizione, mentre questa particolare variazione di INSERT richiede VALUES per risultare completo. La regole precise per la sintassi di ogni comando sono descritte nella Parte VI, «Reference».

4.1.1. Identificatori e parole chiave

Token come SELECT, UPDATE, o VALUES citati in precedenza sono esempi di parole chiave, ovvero parole che hanno un significato preciso nel linguaggio SQL. I token MY_TABLE e A sono esempi di identificatori. Essi identificano nomi di tabelle, colonne o altri oggetti del database a seconda del comando in cui vengono usati. Per questo a volte vengono semplicemente chiamati «nomi». Le parole chiave e gli identificatori hanno la stessa struttura lessicale, quindi non è possibile sapere se un token è un identificatore o una parola chiave senza conoscere il linguaggio. Un elenco completo di parole chiave si trova in Appendice C, Parole chiave SQL.

Identificatori e parole chiave SQL devono cominciare con una lettera (a-z, ma anche lettere con segni diacritici e lettere non Latine) o un underscore (_). I successivi caratteri di un identificatore o parola chiave possono essere lettere, underscore, cifre (0-9) o segni dollaro ($). Si noti che il segno dollaro non è permessi negli identificatori in accordo con lo standard SQL, per questo il loro uso potrebbe rendere le applicazioni meno portabili. Inoltre, siccome lo standard SQL non definirà mai parole chiave che contengano cifre oppure che comincino o finiscano con un carattere underscore, gli identificatori scritti in questa forma sono al sicuro da eventuali conflitti con estensioni future dello standard.

Il sistema non usa più di NAMEDATALEN-1 byte di un identificatore; nomi più lunghi possono essere scritti nei comandi, ma verranno troncati. Di default, NAMEDATALEN è 64 e quindi la lunghezza massima per gli identificatori è 63 byte. Se questo limite dovesse rappresentare un problema, può essere alzato cambiando la costante NAMEDATALEN in src/include/pg_config_manual.h.

Parole chiave e identificatori non quotati sono case-insensitive e pertanto possono essere scritti indifferentemente con caratteri maiuscoli o minuscoli. Perciò:

UPDATE MY_TABLE SET A = 5;

può essere scritto equivalentemente:

uPDaTE my_TabLE SeT a = 5;

Una convenzione usata spesso è di scrivere le parole chiave in maiuscolo e i nomi in minuscolo, per es.:

UPDATE my_table SET a = 5;

Esiste anche un altro tipo di identificatore: l'identificatore delimitato o identificatore quotato. Viene formato racchiudendo una sequenza arbitraria di caratteri fra doppi apici ("). Un identificatore delimitato è sempre un identificatore, mai una parola chiave. Per questo motivo, ad esempio, "select" potrebbe essere usato per fare riferimento a una colonna o a una tabella chiamata «select», mentre select (non quotato) verrebbe considerato una parola chiave e pertanto provocherebbe un errore se usato laddove il nome di una tabella o di una colonna fosse atteso. L'esempio può essere scritto con indentificatori quotati nel seguente modo:

UPDATE "my_table" SET "a" = 5;

Gli identificatori quotati possono contenere qualsiasi carattere, ad eccezioni del carattere con codice zero (per inserire un carattere di doppi apici, scrivere due doppi apici). Questo permette la creazione di nomi di tabelle o colonne che non sarebbero altrimenti possibili, tipo nomi contenenti spazi o e commerciali ('&'). Viene comunque applicata la limitazione della lunghezza.

Una variante degli identificatori quotati permette di inserire caratteri Unicode identificati dai loro codici. Questa variante comincia con U& (U, maiuscola o minuscola, seguita da una e commerciale) immediatamente prima del carattere di apice doppia, senza alcuno spazio fra essi. Ad esempio: U&"foo". Si noti che ciò genera ambiguità con l'operatore &: per evitare questo problema è possibile inserire spazi intorno all'operatore. All'interno degli apici, i caratteri Unicode possono essere specificati nella forma escaped, ovvero inserendo un carattere di backslash ('\', barra inversa) seguito dal codice di quattro cifre esadecimali oppure alternativamente dal segno più ('+') e dal codice di sei cifre esadecimali. Ad esempio, l'identificatore "data" potrebbe essere scritto come

U&"d\0061t\+000061"

Il seguente e meno banale esempio scrive la parola russa «slon» (elefante) in caratteri cirillici:

U&"\0441\043B\043E\043D"

Se si desidera usare un carattere di escape diverso dalla barra inversa, è possibile specificarlo usando la clausola UESCAPE dopo la stringa, per esempio:

U&"d!0061t!+000061" UESCAPE '!'

Il carattere di escape può essere un singolo carattere piuttosto che una cifra decimale, il segno più, un singolo apice, doppi apici, o un carattere di spazio. Notare che il carattere di escape è scritto in singoli apici e non doppi.

Per inserire il carattere di escape letteralmente nell'identificatore, è necessario scriverlo due volte.

La sintassi di escape Unicode funziona solo quando la codifica del server è UTF8. Quando sono usate altre codifiche per il server, possono essere specificati solo codici nell'intervallo ASCII (fino a \007F). Sia la forma a 4 cifre che quella a 6 cifre possono essere usate per specificare coppie surrogate UTF-16 e comporre caratteri con codici più grandi di U+FFFF, anche se la disponibilità della forma a 6 cifre tecnicamente la rende non necessaria. (Quando le coppie surrogate sono usate con server che usano codifica UTF8, esse sono prima combinate in un singolo codice che viene codificato in UTF-8).

Quotare un identificatore significa renderlo rende anche sensibile al case, mentre nomi non quotati sono sempre resi in minuscolo. Per esempio, gli identificatori FOO, foo, e "foo" sono considerati allo stesso modo da PostgreSQL™, ma "Foo" e "FOO" sono diversi da quei tre e anche tra di loro. (Il comportamento di PostgreSQL™ di rendere nomi non quotati in minuscolo non è compatibile con lo standard SQL, che dice che i nomi non quotati dovrebbero essere resi in maiuscolo. Così, foo dovrebbe essere equivalente a "FOO", non a "foo", secondo lo standard. Si suggerisce di quotare sempre o non quotare mai un particolare nome al fine di scrivere applicationi portabili.

4.1.2. Costanti

Ci sono tre tipi di costanti scritte implicitamente in PostgreSQL™: stringhe, stringhe di bit e numeri. Le costanti possono essere specificate anche con tipi espliciti, che possono abilitare una rappresentazione più accurata e una gestione più efficiente da parte del sistema. Queste alternative sono discusse nelle sottosezioni seguenti.

4.1.2.1. Costanti stringa

Una costante stringa in SQL è una sequenza di caratteri arbitraria racchiusa in apici singoli ('), per esempio 'Questa è una stringa'. Per includere un carattere di singolo apice all'interno di una costante stringa, scrivere due apici singoli adiacenti, per es., 'Dianne''s horse'. Notare che questo non è lo stesso di un carattere doppio apice (").

Due costanti stringa che sono separate solamente da spazi bianchi con al meno una nuova linea sono concatenate e trattate effettivamente come se la stringa sia stata scritta come una costante. Per esempio:

SELECT 'foo'
'bar';

è equivalente a:

SELECT 'foobar';

ma:

SELECT 'foo'      'bar';

Non è sintassi valida. (Questo comportamento un po' bizzarro è specificato da SQL; PostgreSQL™ segue lo standard).

4.1.2.2. Costanti striga con escape in stile C

PostgreSQL™ accetta anche costanti stringa di «escape», che sono un'estensione dello standard SQL. Una costante stringa di escape viene specificata scrivendo la lettera E /in maiuscolo o minuscolo) appena prima dell'apertura del singolo apice, per es., E'foo'. (Quando si continua una stringa di escape attraverso linee, scrivere E solo prima dell'apertura del primo apice). All'interno di una stringa di escape, un carattere barra inversa (\) indica l'inizio di una sequenza backslash escape stile C, in cui la combinazione della barra inversa e il seguente carattere/i rappresenta un valore speciale, come mostrato nella Tabella 4.1, «Sequenze di escape con barre inverse».

Tabella 4.1. Sequenze di escape con barre inverse

Sequenza di escape con barra inversaInterpretazione
\bbackspace
\fform feed
\nnuova linea
\rritorno carrello
\ttab
\o, \oo, \ooo (o = 0 - 7) valore ottale di byte
\xh, \xhh (h = 0 - 9, A - F) valore esadecimale di byte
\uxxxx, \Uxxxxxxxx (x = 0 - 9, A - F) valore esadecimale di carattere Unicode a 16 or 32-bit

Qualsiasi altro carattere che segue una barra inversa viene preso letteralmente. Per questo, per includere un carattere di barra inversa, scrivere due barre inverse (\\). Inoltre, in una stringa di escape può esssere incluso un singolo apice scrivendo \', in aggiunta al normale modo ''.

È propria responsabilità che le sequenze di byte create, specialmente quando si usano escape ottali o esadecimali, compongano caratteri validi nella codifica di caratteri del server. Quando la codifica del server è UTF-8, allora dovrebbero essere usati escape Unicode o la sintassi di escape alternativa Unicode, spiegata in Sezione 4.1.2.3, «Costanti stringa con escape Unicode». (L'alternativa sarebbe usare codifica UTF-8 a mano e scrivere i byte, ,a sarebbe molto ingombrante).

La sintassi escape Unicode funziona a pieno solo quando la codifica del server è UTF8. Quando sono usate altre codifiche del server, possono essere specificati solo codici nell'intervallo ASCII (fino a \u007F). Sia la forma a 4 cifre che quella a 8 cifre possono essere usate per specificare coppie surrogate UTF-16 per comporre caratteri con codici maggiori di U+FFFF, anche se la disponibilità della forma a 8 cifre tecnicamente lo rende non necessario. (Quando coppie surrogate sono usate con server codificati UTF8, vengono prima combinate in singoli codici che poi sono codificate in UTF-8).

[Attenzione]

Attenzione

Se il parametro di configurazione standard_conforming_strings è off, allora PostgreSQL™ riconosce escape backslash sia in costanti stringa normali che escape. Comunque, a partire da PostgreSQL™ 9.1, in maniera predefinita sarà impostato on, ciò significa che escape backslash sono riconosciuti solo in costanti stringa di escape. Questo comportamento è più attinente allo standard, ma potrebbe rompere applicazioni che si basano sul comportamento storico, dove gli escape backslash erano sempre riconosciuti. Come workaround, è possibile impostare questo parametro a off, ma è meglio abituarsi a non usare escape backslash. Se si ha bisogno di usare l'escape backslash per rappresentare un carattere speciale, scrivere la costante stringa con una E.

In aggiunta a standard_conforming_strings, i parametri di configurazione escape_string_warning e backslash_quote governano il trattamento delle barre inverse nelle costanti stringa.

Il carattere con il codice zero non può apparire in una costante stringa.

4.1.2.3. Costanti stringa con escape Unicode

PostgreSQL™ supporta anche un altro tipo di sintassi di escape per stringhe che permette di specificare caratteri arbitrari Unicode attraverso un codice. Una stringa costante di escape Unicode comincia con U& (lettera U maiuscola o minuscola seguita da e commerciale) immediatamente prima l'apice di apertura. senza spazi tra di loro, per esempio U&'foo'. (Notare che questo crea un'ambiguità con l'operatore &. Usare spazi intorno all'operatore per evitare questo problema). All'interno degli apici, possono essere specificati caratteri Unicode in formato escape scrivendo una barra inversa seguita dal codice a 4 cifre esadecimali o alternativamente una barra inversa seguita da un segno più seguito da un codice a sei cifre esadecimali. Per esempio, la stringa 'data' potrebbe essere scritta come

U&'d\0061t\+000061'

Questo esempio scrive la parola russa «slon» (elefante) in alfabeto cirillico.

U&'\0441\043B\043E\043D'

Se si desidera usare un carattere di escape diverso dalla barra barra inversa, può essere specificato usando la clausola UESCAPE dopo la stringa, per esempio:

U&'d!0061t!+000061' UESCAPE '!'

Il carattere di escape può essere qualsiasi singolo carattere diverso da una cifra esadecimale, il segno più, un apice singolo, un doppio apice, o un carattere di spazio.

La sintassi escape Unicode funziona solo quando la codifica del server è UTF8. Quando sono usate altre codifiche per il server, possono essere specificati solo codici nell'intervallo ASCII (fino a \007F). Possono essere usate sia la forma a 4 cifre che quella a 6 cifre per specificare coppie surrogate UTF-16 per comporre caratteri con codici maggiori di U+FFFF, anche se la disponibilità della forma a 6 cifre lo rende non necessario. (Quando coppie surrogate vengono usate con serve che utilizzano codifica UTF8, sono prima di tutto combinate in un singolo codice che poi viene codificato in UTF-8).

Comunque, la sintassi escape Unicode per costanti stringa funziona solo quando il parametro di configurazione standard_conforming_strings è impostato ad on. Questo perchè altrimenti questa sintassi potrebbe condondere client che effettuano il parsing di istruzioni SQL al punto da provocare a injenction SQL e problemi di sicurezza simili. Se il parametro è impostasto ad off, questa sintassi sarà rifiutata generando un messaggio di errore.

Per includere il carattere di escape letteralmente nella stringa, scriverlo due volte.

4.1.2.4. Costanti stringa quotate da dollari

Mentre la sintassi standard per specificare costanti stringa di solito è conveniente, può essere difficile da capire quando la stringa desiderata contiene moli singoli apici o barre inverse, dato che ognuna di queste deve essere raddoppiata. Per permettere query più leggibili in quelle situazioni, PostgreSQL™ fornisce un altro modo, chiamato «quotazione con dollari», per scrivere costanti stringa. Una costante stringa quotata con dollari consiste di un segno dollaro ($), un «tag» di zero o più caratteri, un altro segno dollaro, una sequenza di caratteri arbitraria che costituisce il contenuto della stringa, un segno dollaro, lo stesso tag che ha cominciato la sequenza, e un sengo dollaro. Per esempio, ecco due modi diversi di specificare la stringa «Dianne's horse» usando la quotazione con dollari:

$$Dianne's horse$$
$SomeTag$Dianne's horse$SomeTag$

Si noti che all'interno della stringa quotata con dollari, i songoli apici possono essere usati senza il bisogno di essere sottoposti ad escape. Effettivamente, nessun carattere usato all'interno di una stringa quotata da dollari viene sottoposto ad escape: il contenuto della stringa è sempre scritto letteralmente. Le barre inverse non sono speciali, e non lo sono nemmeno i segni dollaro, a meno che non siano parte di una sequenza corrispondente al tag d'apertura.

È possibile annidare costanti stringa quotate con dollari scegliendo tag diversi ad ogni livello di annidamento. Questo viene usato comunemente per scrivere definizioni di funzione. Per esempio:

$function$
BEgin
    RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$

Qui, la sequenza $q$[\t\r\n\v\\]$q$ rappresenta una stringa quotata da dolarri [\t\r\n\v\\], che sarà riconosciuta quando il corpo della funzione viene eseguito da PostgreSQL™. Ma dal momento che la sequenza non corrisponde al delimitatore esterno della quotazione dollaro $function$, è solamente qualche carattere in più all'interno della costante per come la stringa esterna è concepita.

Il tag, se presente, di una stringa quotata da dollari, segue le stesse regole di un identificatore non quotato, eccetto che non può contenere un segno dollaro. I tage sono sensibili al case, così $tag$Contenuto della stringa$tag$ è corretto, ma $TAG$Contenuto della stringa$tag$ non lo è.

Una stringa quotata da dollari che seque una parola chiave o un identificatore dev'essere separata da essa da spazi bianchi; altrimenti il delimitatore di quotazione sarebbe preso come parte del precedente identificatore.

La quotazione con dollari non fa parte dello standard SQL, ma spesso è un modo più conveniente di scrivere letterali stringa complicati rispetto alla sintassi con singoli apici che aderisce allo standard. È particolarmente utile quando si rappresentano costanti stringa all'interno di altre costanti, come spesso è necessario in definizioni di funzioni procedurali. Con la sintassi a singolo apice, ogni barra inversa nell'esempio sopra dovrebbe essere scritta come quattro barre inverse, che sarebbero ridotte a due barre inverse nel parsing della costante stringa originale, e quindi ad una quando viene ri-eseguito il parsing della costante stringa interna durante l'esecuzione della funzione.

4.1.2.5. Costanti stringa di bit

Le costanti stringa di bit somigliano a costanti stringa regolari con una B (maiuscola o minuscola) immediatamente prima dell'apice di apertura (senza spazi), per es., B'1001'. I soli caratteri permessi all'interno di costanti a stringa di bit sono 0 e 1.

Alternativamente, le costanti stringa di bit possono essere specificate in notazione esadecimale, usando una X in testa (maiuscola o minuscola), per es., X'1FF'. Questa notazione è equivalente a una costante stringa di bit con quattro cifre binarie per ogni cifra esadecimale.

Tutt'e due le forme di costanti stringa di bit possono essere estese su più linee nello stesso modo di costanti stringa regolari. La quotazione con dollari non può essere usata in una costante stringa di bit.

4.1.2.6. Costanti numeriche

Le costanti numeriche sono accettate in queste forme:

digits
digits.[digits][e[+-]digits]
[digits].digits[e[+-]digits]
digitse[+-]digits

dove digits è una o più cifre (da 0 a 9). Deve esserci almeno una cifra prima o dopo il punto decimale, se usato. Almeno una cifra deve seguire l'indicatore di esponente (e), se presente. Non ci puà essere nessuno spazio o altro carattere incluso nella costante. Si noti che qualsiasi segno più o meno in testa non viene considerato parte della costante; è un operatore applicato alla costante.

Questi sono esempi di costanti numeriche valide:


42
3.5
4.
.001
5e2
1.925e-3

Una costante numerica che non contiene nè un punto decimale e nemmeno un esponente viene supposto sia del tipo integer se il suo valore rientra nel tipo integer (32 bit); altrimenti si presume essere del tipo bigint se il suo valore rientra nel tipo bigint (64 bit); altrimenti viene cosiderata di tipo numeric. Le costanti che contengono punti decimali e/o esponenti sono sempre considerate essere del tipo numeric.

Il tipo di dato assegnato inizialmente a una costante numerica è solo un punto di partenza per gli algoritmi di risoluzione del tipo. Nella maggior parte dei casi la costante sarà forzata automaticamente al tipo appropriato in funzione del contesto. Quando necessario, è possibile forzare che un valore numerico sia interpretato come un tipo di dato specifico convertendolo. Per esempio, è possibile forzare che un valore numerico sia trattato come real (float4) scrivendo:

REAL '1.23'  -- stile stringa
1.23::REAL   -- stile PostgreSQL (storico)

Questi effettivamente sono solo casi speciali delle notazioni di conversione discusse successivamente.

4.1.2.7. Costanti di altri tipi

Una costante di un tipo arbitrario può essere specificata usando una delle seguenti notazioni:

type 'string'
'string'::type
CAST ( 'string' AS type )

Il testo della costante stringa viene passato alla routine di conversione per il tipo chiamato type. Il risultato è una costante del tipo indicato. La conversione esplicita di tipo può essere omessa se non c'è ambiguità sul tipo della costante (per esempio, quando è assegnata direttamente a una colonna di tabella), nel qual caso viene forzata automaticamente.

La costante stringa può essere scritta usando sia la normale notazione SQL sia la quotazione con dollari.

È inoltre possibile specificare la forzatura a un tipo usando una sintassi simile ad una funzione:

typename ( 'string' )

ma non tutti i nomi di tipo possono essere usati in questo modo; si veda Sezione 4.2.9, «Conversioni di tipo» per dettagli.

Le sintassi ::, CAST() e a chimata di funzione, possono essere usate anche per specificare conversioni di tipo di espressioni arbitrarie durante l'esecuzione, come discusso in Sezione 4.2.9, «Conversioni di tipo». Per evitare ambiguità sintattica, la sintassi type 'string' può essere utilizzata solo per specificare il tipo di una semplice costante letterale. Un'altra restrizione sulla sintassi type 'string' è che non funziona per tipi array; usare :: o CAST() per specificare il tipo di una costante array.

La sintassi CAST() è conforme a SQL. La sintassi type 'string' è una generalizzazione dello standard: SQL specifica questa sintassi solo per pochi tipi di dato, ma PostgreSQL™ la permette per tutti i tipi. La sintassi con :: è storica di PostgreSQL™, come la sintassi a chiamata di funzione.

4.1.3. Operatori

Un nome di operatore è una sequenza di caratteri, fino a NAMEDATALEN-1 (63 come predefinito), dal seguente elenco:


+ - * / < > = ~ ! @ # % ^ & | ` ?

ci sono comunque alcune restrizioni sui nomi di operatore:

  • -- e /* non possono apparire nel nome di un operatore, dato che saranno presi come inizio di un commento.

  • Un nome di operatore comporto da molteplici caratteri non può terminare con + o -, a meno che il nome contenga anche almeno uno di questi caratteri:


    ~ ! @ # % ^ & | ` ?

    Per esempio, @- è un nome di operatore permesso, ma *- no. Questa restrizione permette a PostgreSQL™ di effettuare il aprsing di query che rispettano lo standard SQL senza richiedere spazi tra i token.

Quando si lavora con nomi di operatori SQL non standard, si avrà di solito bisogno di separare operatori adiacenti con spazi per evitare ambiguità. Per esempio, se si è definito un operatore unario di sinistra chiamato @, non si puà scrivere X*@Y; si deve scrivere X* @Y per essere sicuri che PostgreSQL™ lo legga come due nomi di operatore e non uno.

4.1.4. Caratteri speciali

Alcuni caratteri che non sono alfanumerici hanno un significato speciale che è diverso dall'essere un operatore. Dettagli sull'utilizzo possono essere trovati nel luogo dove il rispettivo elemento di sintassi è descritto. Questa sezione esiste solo per notificarne l'esistenza e riassumere gli scopi di questi caratteri.

  • Un segno dollatro ($) seguito da cifre viene usato per rappresentare un parametro posizionale nel corpo di una definizione di funzione o di una funzione preparata. In altri contesti il segno dollaro può essere parte di un identificatore o di una costante stringa quotata con dollari.

  • Le parentesi tonde (()) hanno il loro solito significato di raggrupare espressioni ed esprimere le precedenze. In alcuno casi le parentesi sono richieste come parte della sintassi fissata di un particolare comando SQL.

  • Le parentesi quadre ([]) vengono usate per selezionare elementi di un array. Si veda Sezione 8.14, «Array» per maggiori informazioni sugli array.

  • Le virgole (,) sono usate in alcuni costrutti sintattici per separare gli elementi di un elenco.

  • Il punto e virgola (;) termina un comando SQL. Non può apparire all'interno di un comando, eccetto all'interno di una costante stringa o indetificatore quotato.

  • I due punti (:) sono usati per selezionare «fette» di un array. (Si veda Sezione 8.14, «Array»). In certi dialetti SQL (tipo Embedded SQL), i due punti sono usati come prefisso per i comi di variabili.

  • L'asterisco (*) viene usato in alcuni contesti per denotare tutti i campi della riga di una tabella o valori composti. Ha inoltre un significato speciale quando usato come argomento di una funzione aggregata, cioè che l'aggregata non richiede nessun parametro esplicito.

  • Il punto (.) viene usato in costanti numeriche, e per separare nomi di schemi, tabelle e colonne.

4.1.5. Commenti

A comment is a sequence of characters beginning with Un commento è una sequenza di caratteri che cominciano con double dashes and extending to the end of the line, e.g.: doppi trattini e si estende fino alla fine della linea, per es.:

-- This is a standard SQL comment

In alternativa, possono essere usati commenti stile C:

/* multiline comment
 * with nesting: /* nested block comment */
 */

dove il commento inizia con /* e si estende fino all'occorrenza corrispondente */. Questi blocchi di commenti possono essre annidati, come specificato nello standard SQL ma non dal C, così è possibile commentare blocchi di commenti più grandi di codice che potrebbe contenere blocchi di commenti.

Un commento viene rimosso dallo stream di input prima di ulteriori analisi di sintassi e viene effettivamente sostituito da spazi bianchi.

4.1.6. Precedenza lessicale

[Nota]

Nota

Nota per il revisore: TODO

Tabella 4.2, «Precedenza degli operatori (decrescente)» shows the precedence and associativity of the operators in PostgreSQL™. Most operators have the same precedence and are left-associative. The precedence and associativity of the operators is hard-wired into the parser. This can lead to non-intuitive behavior; for example the Boolean operators < and > have a different precedence than the Boolean operators <= and >=. Also, you will sometimes need to add parentheses when using combinations of binary and unary operators. For instance:

SELECT 5 ! - 6;

sarà sottoposto a parsing come:

SELECT 5 ! (- 6);

because the parser has no idea -- until it is too late -- that ! is defined as a postfix operator, not an infix one. To get the desired behavior in this case, you must write:

SELECT (5 !) - 6;

Questo è il prezzo che si paga per l'estendibilità.

Tabella 4.2. Precedenza degli operatori (decrescente)

Operatore/ElementoAssociativitàDescrizione
.sinistraseparatore di nomi di tabella/colonna
::sinistracast di tipo in stile PostgreSQL
[ ]sinistraselezione di elemento di un array
-destrameno unario
^sinistraesponenziale
* / %sinistramoltiplicazione, divisione, modulo
+ -sinistraaddizione, sottrazione
IS IS TRUE, IS FALSE, IS UNKNOWN, IS NULL
ISNULL test per null
NOTNULL test per non null
(qualsiasi altro)sinistratutti gli altri operatori nativi e definiti dall'utente
IN appartenenza all'insieme
BETWEEN appartenenza all'intervallo
OVERLAPS sovrapposizione dell'intervallo di tempo
LIKE ILIKE SIMILAR corrispondenza di modelli di stringa
< > minore di, maggiori di
=destrauguaglianza, assegniazione
NOTdestranegazione logica
ANDsinistracongiunzione logica
ORsinistradisgiunzione logica

Natare che le regole di precedenza degli operatori si applicano anche a operatori definiti dall'utente che hanno gli stessi nomi degli operatori inclusi menzionati sopra. Per esempio, se si definisce un operatore «+» per qualche tipo di dato personalizzato, esso avrà la stessa precedenza dell'operatore incluso «+», non importa cosa faccia.

Quando un operatore qualificato da schema viene usato nella sintassi OPERATOR, come per esempio in:

SELECT 3 OPERATOR(pg_catalog.+) 4;

il costrutto OPERATOR è assunto avere la precedenza predefinita mostrata nella Tabella 4.2, «Precedenza degli operatori (decrescente)» per l'operatore «qualsiasi altro». Questo è vero qualunque sia l'operatore specificato all'interno di OPERATOR().

Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Sintassi SQL
PrecedenteIl linguaggio SQLEspressioni di valoreSuccessivo