Skip site navigation (1) Skip section navigation (2)

Re: LargeObject API and OIDs

From: Christian Niles <christian(at)unit12(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: LargeObject API and OIDs
Date: 2004-10-25 15:20:45
Message-ID: 70EC5AC2-2699-11D9-89C4-000A9590B78E@unit12.net (view raw or flat)
Thread:
Lists: pgsql-jdbc
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(at)unit12(dot)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
>


In response to

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2004-10-25 21:00:51
Subject: Re: Problems with protocol V3 after migration to latest driver
Previous:From: Tom LaneDate: 2004-10-25 14:28:00
Subject: Re: LargeObject API and OIDs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group