From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BLOB support |
Date: | 2011-06-02 17:43:16 |
Message-ID: | 5431.1307036596@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?utf-8?q?Rados=C5=82aw_Smogura?= <rsmogura(at)softperience(dot)eu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-02 17:53:08 | Re: InitProcGlobal cleanup |
Previous Message | Andrew Dunstan | 2011-06-02 17:15:07 | Re: Please test peer (socket ident) auth on *BSD |