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 по дате отправления: