La mayoría de los sistemas de bases de datos proporcionan un tipo de datos que puede almacenar datos sin procesar, y PostgreSQL no es una excepción. Uso el término datos sin procesar para indicar que la base de datos no entiende la estructura o el significado de un valor. En contraste, PostgreSQL entiende la estructura y el significado de otros tipos de datos. Por ejemplo, cuando define una columna ENTERA, PostgreSQL sabe que los bytes de datos que coloca en esa columna representan un valor entero. PostgreSQL sabe qué es un entero?puede agregar enteros, multiplicarlos, convertirlos hacia y desde la forma de cadena, y así sucesivamente. Los datos en bruto, por otro lado, ¿son solo una colección de bits?PostgreSQL no puede inferir ningún significado en los datos.

PostgreSQL ofrece el tipo BYTEA para almacenar datos sin procesar. Una columna de BYTEA puede contener teóricamente valores de cualquier longitud, pero parece que la longitud máxima es de 1 GB.

El tamaño de un valor de BYTE es de 4 bytes más el número real de bytes en el valor.

Sintaxis para valores literales

Introducir un valor de BYTEA puede ser un poco complicado. Un literal de BYTEA se introduce como un literal de cadena: es solo una cadena de caracteres encerrada entre comillas simples. Teniendo esto en cuenta, ¿cómo se introduce un valor de BYTEA que incluye una sola cotización? Si mira hacia atrás a la discusión de los valores literales de cadena (anterior en este capítulo), verá que puede incluir caracteres especiales en un valor de cadena escapándolos. En particular, una comilla simple puede escaparse de una de tres maneras:

  • Duplique las comillas simples(‘ Esta es una comilla simple»‘)

  • Precede a la comilla simple con una barra invertida(‘ Esta es una comilla simple\»)

  • Incluya el valor octal del carácter en su lugar(‘ Esto es una comilla simple\047’)

Hay otros dos personajes que debes escapar al entrar en BYTEA literals. Un byte cuyo valor es cero (no el carácter 0, sino el byte nulo) debe escaparse, y el carácter de barra invertida debe escaparse. Puede escapar cualquier carácter usando la forma «\ \ ddd » (donde ddd es un número octal). Puede escapar de cualquier carácter imprimible utilizando el formulario «\ \ c». Por lo tanto, si desea almacenar un valor de BYTE que incluya un byte cero, puede ingresarlo de esta manera:

'This is a zero byte \000'

Si desea almacenar un valor de BYTEA que incluya una barra invertida, puede ingresarlo en cualquiera de los siguientes formularios:

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

Si compara estas reglas con las reglas para citar literales de cadena, notará que los literales de BYTEA requieren el doble de caracteres de barra invertida. Esta es una peculiaridad del diseño del analizador de PostgreSQL. Los literales de BYTEA son procesados por dos analizadores diferentes. El analizador principal de PostgreSQL ve un literal de BYTEA como un literal de cadena (engullendo el primer conjunto de caracteres de barra invertida). A continuación, el analizador de BYTEA procesa el resultado, engullendo el segundo conjunto de caracteres de barra invertida.

Por lo tanto, si tiene un valor de BYTEA como Esto es una barra invertida \, lo cita como ‘Esto es una barra invertida \\\\’. Después de que el analizador sintáctico de cadenas procese esta cadena, se ha convertido en ‘Esto es una barra invertida \\’. El analizador de BYTEA finalmente transforma esto en Esto es una barra invertida \.

Operadores soportados

PostgreSQL ofrece un único operador de BYTEA: concatenación. Puede añadir un valor de BYTEA a otro valor de BYTEA utilizando el operador de concatenación ( | | ).

Tenga en cuenta que no puede comparar dos valores de BYTEA, ni siquiera para igualdad/desigualdad. Por supuesto, puede convertir un valor de BYTEA en otro valor usando el operador CAST (), y eso abre otros operadores.

Objetos grandes

El tipo de datos BYTEA se limita actualmente a almacenar valores no mayores de 1 GB. Si necesita almacenar valores más grandes que los que caben en una columna de BYTEA, puede usar objetos grandes. Un objeto grande es un valor almacenado fuera de una tabla. Por ejemplo, si desea almacenar una fotografía con cada fila en su tabla tapes, agregaría una columna OID para contener una referencia al objeto grande correspondiente:

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

Cada valor de la columna photo_id se refiere a una entrada de la tabla del sistema pg_largeobject. PostgreSQL proporciona una función que cargará un archivo externo (como un archivo JPEG) en la tabla pg_largeobject:

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

La función lo_import () carga el archivo con nombre en pg_largeobject y devuelve un valor OID que se refiere al objeto grande. Ahora, cuando SELECCIONA esta fila, ve el OID, no los bits reales que componen la foto:

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

Si desea volver a escribir la foto en un archivo, puede usar la función lo_export() :

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

Para ver todos los objetos grandes de la base de datos actual, utilice el metacomando \lo_list de psql:

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

Puede eliminar objetos grandes de su base de datos mediante la función lo_unlink() :

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

¿Cómo se llega a los bits reales detrás del OID de referencia? ¿No puedes?al menos no con psql. La compatibilidad con objetos grandes debe estar integrada en la aplicación cliente que esté utilizando. psql es una herramienta orientada a texto y no tiene forma de mostrar una fotografía, por lo que lo mejor que puede hacer es mirar los datos sin procesar en la tabla pg_largeobject. Algunas aplicaciones cliente, como la estación de trabajo Conjectrix, admiten objetos grandes y, en la mayoría de los casos, pueden interpretar los datos sin procesar correctamente.