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
32bitlength 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
otherdatabases idea that LOBs are not "downloaded" during normal query execution (just ids are taken). Currently, e.g.
LOBsare not connected with tables, so deleting rows doesn't delete LOB, table actually holds Oid of large objects, no
supportfor casting to/from LOB, no support for CLOBS. Some drivers try to emulate BLOBs/CLOBs, but it is not perfect,
mainlyfrom above reasons.
Regards,Radek