Re: BLOB support

On Thu, 02 Jun 2011 15:39:39 +0300, Peter Eisentraut wrote:
> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
>> I partialy implemented following missing LOBs types. Requirement for
>> this was
>> to give ability to create (B/C)LOB columns and add casting
>> functionality e.g.
>> SET my_clob = 'My long text'.
>>
>> Idea is as follow:
>> 0. Blob is two state object: 1st in memory contains just bytea,
>> serialized
>> contains Oid of large object.
>> 1. Each type has additional boolean haslobs, which is set
>> recursivly.
>> 2. Relation has same bool haslobs (used to speed up tables without
>> LOBs)
>> 3. When data are inserted/updated then "special" function is called
>> and tuple
>> is modified in this way all LOBs are serialized to (old) LOB table
>> and just
>> Oid is stored.
>> 4. When removed LOB is removed from (old) LOB table.
>
> Superficially, this looks like a reimplementation of TOAST.
May look similar, but Datums doesn't support more then 32bit length and
size of any field is limited to 1GB, am I right? Serializations is only
for casting simple values < 1GB, and simple operations, to do not
overhead creation of hundreds LOBs.

> What functionality exactly do you envision that the BLOB and CLOB
> types would
> need to have that would warrant treating them different from, say,
> bytea
> and text?

Actually I thought about less sophisticated support of LOBs, supporting
casting and copying data, as well known form other databases idea that
LOBs are not "downloaded" during normal query execution (just ids are
taken). Currently, e.g. LOBs are not connected with tables, so deleting
rows doesn't delete LOB, table actually holds Oid of large objects, no
support for casting to/from LOB, no support for CLOBS. Some drivers try
to emulate BLOBs/CLOBs, but it is not perfect, mainly from above
reasons.

Regards,
Radek