Re: LargeObject API and OIDs

bytea values are a little cumbersome because of their memory 
requirements, and because the ability to seek will likely prove 
valuable at times. The system will be installed in places with small IT 
departments and novice users, so I'm trying to keep the database 
administration simple, and the effects of user ignorance or mistakes 
small.

Implementing a logical block manager of sorts is starting to look like 
the best compromise. Thanks for all your input, it's helped me 
understand the limits of each approach quite well.

best,
christian.

On Oct 25, 2004, at 10:28 AM, Tom Lane wrote:

> Christian Niles  writes:
>> On Oct 24, 2004, at 4:26 PM, Tom Lane wrote:
>>> ... Something involving a bigint identifier
>>> would work better.
>
>> If i understand correctly, you're implying here using a table that
>> mimics the pg_largeobject table, but uses int/bigint identifiers
>> instead of OID.
>
> I was thinking of just a bigint primary key and a bytea data field.
> You would of course have to fool with the bytea value instead of using
> the LargeObject API; dunno how inconvenient this is for you.
>
> 			regards, tom lane
>