Tom Lane <tgl@sss.pgh.pa.us> Thursday 02 of June 2011 19:43:16
> Radosław Smogura <rsmogura@softperience.eu> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> Thursday 02 of June 2011 16:42:42
> >
> >> Yes. I think the appropriate problem statement is "provide streaming
> >> access to large field values, as an alternative to just fetching/storing
> >> the entire value at once". I see no good reason to import the entire
> >> messy notion of LOBS/CLOBS. (The fact that other databases have done it
> >> is not a good reason.)
> >
> > In context of LOBs streaming is resolved... I use current LO
> > functionallity (so driver may be able to read LOBs as psql \lo_export
> > does it or using COPY subprotocol) and client should get just LO's id.
>
> Just to be clear: I do not want to expose a concept of object IDs for
> field values in the first place. All of the problems you enumerate stem
> from the idea that LOBs ought to be a distinct kind of field, and I
> don't buy that.
>
> regards, tom lane
So do I understand good should We think about create bettered TOAST to support
larger values then 30-bit length? I like this much more, but without Objects
ID quering relation with lobs will require to lock relation for some time, as
client will need to reference LOB in some way, I think using TID or some
derivative of TID, am I right?
Regards,
Radek
