a maioria dos sistemas de banco de dados fornece um tipo de dados que pode armazenar dados brutos e o PostgreSQL não é exceção. Eu uso o termo dados brutos para significar que o banco de dados não entende a estrutura ou o Significado de um valor. Em contraste, o PostgreSQL entende a estrutura e o Significado de outros tipos de dados. Por exemplo, quando você define uma coluna inteira, o PostgreSQL sabe que os bytes de dados que você coloca nessa coluna devem representar um valor inteiro. PostgreSQL sabe o que é um inteiro?ele pode adicionar inteiros, multiplicá-los, convertê-los de e para a forma de string e assim por diante. Os dados brutos, por outro lado, são apenas uma coleção de bits?O PostgreSQL não pode inferir nenhum significado nos dados.

PostgreSQL oferece o tipo BYTEA para armazenar dados brutos. Uma coluna bytea pode teoricamente conter valores de qualquer comprimento, mas parece que o comprimento máximo é de 1 GB.

o tamanho de um valor BYTEA é de 4 bytes mais o número real de bytes no valor.

sintaxe para valores literais

inserir um valor BYTEA pode ser um pouco complicado. Um literal bytea é inserido como um literal de string: é apenas uma string de caracteres entre aspas simples. Dado isso, como você insere um valor BYTEA que inclui uma única cotação? Se você olhar para trás para a discussão de valores literais de string( anteriormente neste capítulo), verá que pode incluir caracteres especiais em um valor de string escapando deles. Em particular, uma única proposta pode por escapou em uma das três formas de:

  • Double up aspas simples (‘Esta é a única proposta”‘)

  • Preceder a única cotação, com uma barra invertida (‘Esta é a única proposta \”)

  • Incluir o valor octal de caracteres em vez disso, (‘Esta é a única proposta \047’)

Há dois outros caracteres que você deve escapar ao entrar BYTEA literais. Um byte cujo valor é zero (não o caractere 0, mas o byte nulo) deve ser escapado e o caractere de barra invertida deve ser escapado. Você pode escapar de qualquer caractere usando o formulário” \\ddd ” (onde ddd é um número octal). Você pode escapar de qualquer caractere imprimível usando o formulário” \\c”. Então, se você deseja armazenar um BYTEA valor que inclui um byte zero, você poderia entrar como este:

'This is a zero byte \000'

Se você quiser armazenar um BYTEA valor que inclui uma barra invertida, você pode entrar em qualquer uma das seguintes formas:

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

Se você comparar essas regras para as regras de citação de literais de seqüência de caracteres, você vai notar que BYTEA literais de exigir o dobro de caracteres de barra invertida. Esta é uma peculiaridade do design do analisador PostgreSQL. Os literais bytea são processados por dois analisadores diferentes. O analisador PostgreSQL principal vê um literal bytea como um literal de string (devorando o primeiro conjunto de caracteres de barra invertida). Em seguida, o analisador bytea processa o resultado, engolindo o segundo conjunto de caracteres de barra invertida.

então, se você tem um valor BYTEA como este é uma barra invertida\, Você citá-lo como ‘esta é uma barra invertida\\\’. Depois que o analisador de string processa essa string, ela foi transformada em ‘This is a backslash \\’. O analisador bytea finalmente transforma isso em uma barra invertida \.

operadores suportados

o PostgreSQL oferece um único operador bytea: concatenação. Você pode anexar um valor BYTEA a outro valor bytea usando o operador concatenação ( | | ).

observe que você não pode comparar dois valores BYTEA, mesmo para igualdade/desigualdade. É claro que você pode converter um valor BYTEA em outro valor usando o operador CAST() e isso abre outros operadores.

objetos grandes

o tipo de dados bytea está atualmente limitado a armazenar valores não maiores que 1 GB. Se você precisar armazenar valores maiores do que caberão em uma coluna BYTEA, poderá usar objetos grandes. Um objeto grande é um valor armazenado fora de uma tabela. Por exemplo, se você deseja armazenar uma fotografia com cada linha no seu fitas tabela, você deve adicionar uma coluna OID para manter uma referência para o grande correspondentes objeto:

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

Cada valor na photo_id coluna refere-se a uma entrada no pg_largeobject tabela de sistema. O PostgreSQL fornece uma função que carregará um arquivo externo (como um arquivo JPEG) na tabela pg_largeobject:

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

a função lo_import () carrega o arquivo nomeado em pg_largeobject e retorna um valor OID que se refere ao objeto grande. Agora, quando você SELECIONAR esta linha, você vê o OID, não o real bits que compõem a foto:

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

Se você deseja gravar a foto de volta em um arquivo, você pode usar o lo_export() função:

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

Para ver todos os grandes objetos no banco de dados atual, use do psql \lo_list metacommand:

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

Você pode remover grandes objetos de seu banco de dados usando o lo_unlink() função:

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

como você chega aos bits reais por trás do OID de referência? Não podes?pelo menos não com psql. O suporte a objetos grandes deve ser incorporado ao aplicativo cliente que você está usando. psql é uma ferramenta orientada a texto e não tem como exibir uma fotografia, então o melhor que você pode fazer é olhar para os dados brutos na tabela pg_largeobject. Alguns aplicativos clientes, como a estação de trabalho Conjectrix, suportam objetos grandes e podem interpretar os dados brutos corretamente, na maioria dos casos.