RE: [HACKERS] LONG

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] LONG
Дата
Msg-id 00f301bf454e$4e5ac380$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] LONG  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
>
> > > I am suggesting the longoid is not the oid of the primary or long*
> > > table, but a unque id we assigned just to number all parts of
> the long*
> > > tuple.  I thought that's what your oid was for.
> > >
> > Unfortunately I couldn't follow this issue correctly.
> > Is the format of long value relation different from Jan's original now ?
> >
> >  - At    CREATE   TABLE,   a   long   value   relation   named
> >       "_LONG<tablename>" is created for those tables who need it.
> >       And of course dropped and truncated appropriate. The schema
> >       of this table is
> >
> >           rowid       Oid,          -- oid of our main data row
>
> I am suggesting a unique oid just to store this long value.  The new oid
> gets stored in the primary table, and on every row of the long* table.
>

Hmm,we could delete long values easily using rowid in case of
heap_delete() .......

>
> > Seems we could even update partially(specified chunk_seq only)
> > without problem.
>
> That could be done, but seems too rare because the new data would have
> to be the same length. Doesn't seem worth\xA0it, though others may
> disagree.
>

First,I wanted to emphasize that we don't have to update any long value
tuples if we don't update long values. It's a special case of partial
update.

Second,large object has an feature like this. If we would replace large
object by LONG,isn't it needed ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



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

Предыдущее
От:
Дата:
Сообщение: Warnung!
Следующее
От:
Дата:
Сообщение: Warnung