Re: Large objects.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Large objects.
Date: 2010-09-27 22:16:56
Message-ID: AANLkTi=9RGkFExVkjhMHjzdJWRsg4x8_VEW67E7piKPa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 27, 2010 at 2:25 PM, Dmitriy Igrishin <dmitigr(at)gmail(dot)com> wrote:
> Hey Robert, Tom
>
> Tom, thank you for explanation!
>
>> Ouch.  Letting people write data to where they can't get it back from
>> seems double-plus ungood.
>>
> Robert, yes, I agree with you. This is exactly what I wanted to say.
> I've implemented a stream class in C++ and this circumstance makes
> the code not so clean because I need to take into account the behavior
> of lo_write() and 2GB limit.

On further examination, it appears we're not doing this. The reason
lo_read wasn't returning any data in your earlier example is because
you called it after seeking to the end of the object. If you seek to
the position where the data was written, it works fine.

A fairly plausible argument could be made that we shouldn't allow
reading or writing past 2^31-1, but it now appears to me that the
behavior is at least self-consistent.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-09-28 00:45:10 Re: Help with User-defined function in PostgreSQL with Visual C++
Previous Message Robert Haas 2010-09-27 20:19:09 Re: trailing whitespace in psql table output