Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jun 2, 2011 at 12:53 PM, RadosÅaw Smogura
> <rsmog...@softperience.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
