Re: BLOB support

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

In response to

Responses

Browse pgsql-hackers by date

  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