Re: LargeObject API and OIDs

Поиск
Список
Период
Сортировка
От Christian Niles
Тема Re: LargeObject API and OIDs
Дата
Msg-id 70EC5AC2-2699-11D9-89C4-000A9590B78E@unit12.net
обсуждение исходный текст
Ответ на Re: LargeObject API and OIDs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@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
>


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: LargeObject API and OIDs
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: Problems with protocol V3 after migration to latest driver