O PostgreSQL possui a funcionalidade objeto grande, que fornece acesso na forma de fluxo aos dados dos usuários que são armazenados em uma estrutura especial de objeto grande. O acesso na forma de fluxo é útil quando se trabalha com valores de dados que são muito grandes para serem manuseados convenientemente como um todo.
Este capítulo descreve a implementação, e as interfaces de linguagem de programação e de consulta dos dados objeto grande no PostgreSQL. Nos exemplos deste capítulo é utilizada a biblioteca C libpq, mas a maioria das interfaces de programação nativas do PostgreSQL suportam funcionalidades equivalentes. Outras interfaces podem utilizar internamente a interface de objeto grande para fornecer suporte genérico a valores grandes, mas não são descritas aqui.
O POSTGRES 4.2, predecessor indireto do PostgreSQL, suportava três implementações padrão para objetos grandes: como arquivos externos ao servidor POSTGRES; como arquivos externos gerenciados pelo servidor POSTGRES; e como dados armazenados dentro do banco de dados POSTGRES. Esta situação causava uma confusão considerável entre os usuários. Como conseqüência, somente permaneceu no PostgreSQL o suporte a objetos grandes como dados armazenados dentro do banco de dados. Embora seja mais lento para ser acessado, fornece uma integridade de dados mais rigorosa. Por motivos históricos, este esquema de armazenamento é referido como Inversão de objetos grandes (Inversion large objects) (Ocasionalmente será visto o termo Inversão utilizado com o mesmo significado de objeto grande). Desde o PostgreSQL 7.1 todos os objetos grandes são armazenados em uma tabela do sistema chamada pg_largeobject.
O PostgreSQL 7.1 introduziu o mecanismo apelidado de "TOAST" (fatias), que permite os valores dos dados serem muito maiores que as páginas de dados. Isto tornou a funcionalidade de objeto grande parcialmente obsoleta. Uma vantagem da funcionalidade de objeto grande que permaneceu, é permitir valores com tamanho de até 2 GB, enquanto os campos fatiados (TOASTed) podem ter no máximo 1 GB. Além disso, os objetos grandes podem ser manipulados pedaço a pedaço de maneira muito mais fácil que os campos de dados comuns e, portanto, os limites práticos são consideravelmente diferentes.
