Re: TOAST and TEXT - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: TOAST and TEXT
Date
Msg-id 3BC52D11.7080300@bitmead.com
Whole thread Raw
In response to TOAST and TEXT  (Chris Bitmead <chris@bitmead.com>)
Responses Re: TOAST and TEXT
List pgsql-hackers
>Chris Bitmead <chris@bitmead.com> writes:>> ... I don't>> like the old large object implementation, I need to store
verylarge>> numbers of objects and unless this implementation has changed>> in recent times it won't cut it.>>Have you
lookedat 7.1?  AFAIK it has no particular problem with>lots of LOs.>>Which is not to discourage you from going over to
byteafields instead,>if that model happens to be more convenient for your application.>But your premise above seems
false.

I'm storing emails, which as we know are usually small but occasionally 
huge. OK, I see in the release notes something like "store all large
objects in one table". and "pg_dump" of large objects. That sounds like
maybe LOs are now ok, although for portability with Oracle blobs it
would be nice if they could be embedded in any row or at least appear
to be so from client interface side (Java client for what I'm doing).

BTW, the postgres docs web pages says there is "no limitation" on row
size. Someone should probably update that with the info given in the
last few emails and probably integrate it in the regular doco as well.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for OSX 10.1 and Postgresql 7.3.1
Next
From: Tom Lane
Date:
Subject: Re: row value constructor bug?