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 <christian@unit12.net> 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
>
