Re: BLOB support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BLOB support
Date
Msg-id 5431.1307036596@sss.pgh.pa.us
Whole thread Raw
In response to Re: BLOB support  (Radosław Smogura <rsmogura@softperience.eu>)
Responses Re: BLOB support
Re: BLOB support
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: storing TZ along timestamps
Next
From: Robert Haas
Date:
Subject: Re: Hacking gram.y Error syntax error at or near "MERGEJOIN"