From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Radosław Smogura <rsmogura(at)softperience(dot)eu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BLOB support |
Date: | 2011-06-03 16:08:56 |
Message-ID: | 28491.1307117336@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jun 2, 2011 at 12:53 PM, Radosaw Smogura
> <rsmogura(at)softperience(dot)eu> wrote:
>> 1. No tracking of unused LO (you store just id of such object). You may leak
>> LO after row remove/update. User may write triggers for this, but it is not
>> argument - BLOB type is popular, and it's simplicity of use is quite
>> important. When I create app this is worst thing.
>>
>> 2. No support for casting in UPDATE/INSERT. So there is no way to simple
>> migrate data (e.g. from too long varchars). Or to copy BLOBs.
>>
>> 3. Limitation of field size to 1GB.
> As a general point, it would probably be a good idea to address each
> of these issues separately, and to have a separate discussion about
> each one.
> As to #1 specifically, if you use a text or bytea field rather than a
> large object per se, then this issue goes away. But then you lose the
> streaming functionality. So at least some people here are saying that
> we should try to fix that by adding the streaming functionality to
> text/bytea rather than by doing anything to the large object facility.
#2 is also a problem that only becomes a problem if you insist that LOBs
have to be a distinct kind of value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-03 16:09:01 | Re: pg_basebackup |
Previous Message | Robert Haas | 2011-06-03 16:07:55 | Re: About bug #6049 |