In realtà ci sono tre domande a cui cercherò di rispondere.
-
Qual è lo scopo di
unknown?Questo è il tipo di dati inizialmente assegnato a NULL e letterali stringa nelle istruzioni SQL. Se sono stati assegnati tali valori letterali, digitare
textimmediatamente, sarebbe difficile dedurre il tipo corretto.Ad esempio, vuoi
myfunc('hello')per invocaremyfunc(character varying), ma non esiste un cast di tipo implicito datextacharacter varying(e causerebbe ambiguità se ne creassi uno). -
Perché
SELECT nullrestituisce una colonna di tipounknown?La risposta tradizionale è:perché l'utente non ha specificato il tipo.
Tuttavia, questo comportamento è stato problematico. Ad esempio, se crei una tabella come questa:
CREATE TABLE test AS SELECT 'hello';finiresti con una colonna di tipo
unknown, che è indesiderabile e causerà problemi più avanti. Il tipounknownin realtà non dovrebbe essere visibile dall'utente, ma piuttosto un dettaglio di implementazione.Di conseguenza, questo commit ha cambiato il comportamento da PostgreSQL v10 in poi:Ora qualsiasi
unknowns lasciato in unSELECToRETURNINGlist sono forzati atexte non è possibile creare tabelle con colonne di tipounknown. -
Perché
SELECT NULL UNION SELECT 42funziona, ma nonSELECT NULL UNION SELECT NULL UNION SELECT 42?Ciò è dovuto alle regole di conversione del tipo .
UNIONè associativa a sinistra, quindi quest'ultima query viene interpretata come(SELECT NULL UNION SELECT NULL) UNION SELECT 42;Ora il primo
UNIONsi risolve nel tipo di datitexta causa della regola 3:Ciò provoca un errore quando si tenta di risolvere il tipo per il secondo
UNIONa causa della regola 4:D'altra parte, nella query
SELECT NULL UNION SELECT 42;"NULL" ha il tipo
unknowne "42" ha il tipointeger(il tipo scelto per i valori letterali numerici senza punto decimale).Regola 5
non si applica qui, perché
integernon è un tipo preferito nella sua categoria (che sarebbeoidedouble precision), quindi viene utilizzata la regola 6:Ciò si traduce in un tipo di
integer.