Re: TOAST and TEXT
От | Chris Bitmead |
---|---|
Тема | Re: TOAST and TEXT |
Дата | |
Msg-id | 3BC52D11.7080300@bitmead.com обсуждение исходный текст |
Ответ на | TOAST and TEXT (Chris Bitmead <chris@bitmead.com>) |
Ответы |
Re: TOAST and TEXT
|
Список | 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 по дате отправления: