La maggior parte dei sistemi di database fornisce un tipo di dati in grado di memorizzare dati grezzi e PostgreSQL non fa eccezione. Uso il termine dati grezzi per indicare che il database non comprende la struttura o il significato di un valore. Al contrario, PostgreSQL comprende la struttura e il significato di altri tipi di dati. Ad esempio, quando si definisce una colonna INTERA, PostgreSQL sa che i byte di dati inseriti in quella colonna dovrebbero rappresentare un valore intero. PostgreSQL sa cos’è un intero?può aggiungere numeri interi, moltiplicarli, convertirli da e verso il modulo stringa e così via. I dati grezzi, d’altra parte, sono solo una raccolta di bit?PostgreSQL non può dedurre alcun significato nei dati.

PostgreSQL offre il tipo BYTEA per la memorizzazione di dati grezzi. Una colonna BYTEA può teoricamente contenere valori di qualsiasi lunghezza, ma sembra che la lunghezza massima sia di 1 GB.

La dimensione di un valore BYTEA è di 4 byte più il numero effettivo di byte nel valore.

Sintassi per valori letterali

Inserire un valore BYTEA può essere un po ‘ complicato. Un letterale BYTEA viene inserito come letterale stringa: è solo una stringa di caratteri racchiusi tra virgolette singole. Detto questo, come si inserisce un valore BYTEA che include una singola citazione? Se si guarda indietro alla discussione dei valori letterali delle stringhe (in precedenza in questo capitolo), si vedrà che è possibile includere caratteri speciali in un valore stringa sfuggendoli. In particolare, un apice singolo può fuggito in uno dei tre modi:

  • Raddoppiare gli apici singoli (‘Questo è un apice singolo”‘)

  • Precedere l’apice singolo con una barra rovesciata (‘Questo è un apice singolo \”)

  • Includere il valore ottale del personaggio, invece, (‘Questo è un apice singolo \047’)

Ci sono altri due personaggi che si deve fuggire quando si entra in BYTEA letterali. Un byte il cui valore è zero (non il carattere 0, ma il byte null) deve essere escape e il carattere backslash deve essere escape. Puoi sfuggire a qualsiasi carattere usando il modulo” \ \ ddd ” (dove ddd è un numero ottale). È possibile sfuggire a qualsiasi carattere stampabile utilizzando il modulo “\ \ c”. Quindi, se vuoi memorizzare un valore BYTEA che include un byte zero, puoi inserirlo in questo modo:

'This is a zero byte \000'

Se si desidera memorizzare un valore BYTEA che include una barra rovesciata, è possibile inserirlo in uno dei seguenti moduli:

'This is a backslash \\''This is also a backslash \134'

Se si confrontano queste regole con le regole per citare i letterali stringa, si noterà che i letterali BYTEA richiedono il doppio dei caratteri backslash. Questa è una stranezza del design del parser PostgreSQL. I letterali BYTEA vengono elaborati da due parser diversi. Il parser principale di PostgreSQL vede un letterale di BYTEA come un letterale di stringa (inghiottendo il primo set di caratteri backslash). Quindi, il parser BYTEA elabora il risultato, inghiottendo il secondo set di caratteri backslash.

Quindi, se hai un valore BYTEA come This is a backslash \, lo citi come ‘This is a backslash\\\’. Dopo che il parser stringa elabora questa stringa, è stato trasformato in ‘Questo è un backslash\’. Il parser BYTEA finalmente trasforma questo in Questo è un backslash \.

Operatori supportati

PostgreSQL offre un singolo operatore BYTEA: concatenazione. È possibile aggiungere un valore BYTEA a un altro valore BYTEA utilizzando l’operatore concatenazione ( | | ).

Si noti che non è possibile confrontare due valori BYTEA, anche per uguaglianza/disuguaglianza. È possibile, naturalmente, convertire un valore BYTEA in un altro valore utilizzando l’operatore CAST () e che apre altri operatori.

Oggetti di grandi dimensioni

Il tipo di dati BYTEA è attualmente limitato alla memorizzazione di valori non superiori a 1 GB. Se è necessario memorizzare valori più grandi di quelli inseriti in una colonna BYTEA, è possibile utilizzare oggetti di grandi dimensioni. Un oggetto di grandi dimensioni è un valore memorizzato all’esterno di una tabella. Ad esempio, se si desidera memorizzare una fotografia con ogni riga nella tabella nastri, è necessario aggiungere una colonna OID per contenere un riferimento all’oggetto di grandi dimensioni corrispondente:

movies=# ALTER TABLE tapes ADD COLUMN photo_id OID;ALTER

Ogni valore nella colonna photo_id fa riferimento a una voce nella tabella di sistema pg_largeobject. PostgreSQL fornisce una funzione che caricherà un file esterno (ad esempio un file JPEG) nella tabella pg_largeobject:

movies=# INSERT INTO tapes VALUESmovies-# (movies(# 'AA-55892',movies(# 'Casablanca',movies(# lo_import('/tmp/casablanca.jpg' )movies(# );

La funzione lo_import() carica il file denominato in pg_largeobject e restituisce un valore OID che fa riferimento all’oggetto large. Ora, quando si SELEZIONA questa riga, si vede l’OID, non i bit effettivi che compongono la foto:

movies=# SELECT * FROM tapes WHERE title = 'Casablanca'; tape_id | title | photo_id----------+------------+---------- MC-68873 | Casablanca | 510699

Se si desidera scrivere la foto di nuovo in un file, è possibile utilizzare il lo_export() funzione:

movies=# SELECT lo_export( 510699, '/tmp/Casablanca.jpg' ); lo_export----------- 1(1 row)

Per vedere tutti i grandi oggetti nel database corrente, utilizzare psql s \lo_list metacommand:

movies=# \lo_list Large objects ID | Description--------+------------- 510699 |(1 row)

È possibile rimuovere grandi oggetti dal database utilizzando il lo_unlink() funzione:

movies=# SELECT lo_unlink( 510699 ); lo_unlink----------- 1(1 row)movies=# \lo_list Large objects ID | Description----+-------------(0 rows)

Come si arriva ai bit effettivi dietro l’OID di riferimento? Non puoi?almeno non con psql. Il supporto per oggetti di grandi dimensioni deve essere integrato nell’applicazione client che si sta utilizzando. psql è uno strumento orientato al testo e non ha modo di visualizzare una fotografia, quindi il meglio che puoi fare è guardare i dati grezzi nella tabella pg_largeobject. Alcune applicazioni client, come la workstation Conjectrix, supportano oggetti di grandi dimensioni e possono interpretare correttamente i dati grezzi, nella maggior parte dei casi.