RE: [HACKERS] LONG

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
> 
> > >
> > > >     The  solution  I see is to give any out of line datum another
> > > >     Oid, that is  part  of  it's  header  and  stamped  into  the
> > > >     reference  data.  That way, the long attribute lookup can use
> > > >     SnapshotAny using this  Oid,  there  can  only  be  one  that
> > > >     exists,  so SnapshotAny is safe here and forces that only the
> > > >     visibility of the master tuple in the main  table  counts  at
> > > >     all.
> > >
> > > This is a great idea.  Get rid of my use of the attribute 
> number.  Make
> > > the varlena long value be:
> > >
> > >    long-bit|length|longrelid|longoid|longlen
> > >
> > > No need for attno in there anymore.
> > 
> >     I  still  need  it  to  explicitly  remove  one long value on
> >     update, while the other one is untouched. Otherwise  I  would
> >     have  to  drop  all  long  values  for  the  row together and
> >     reinsert all new ones.
> 
> 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
needit.     And of course dropped and truncated appropriate. The schema     of this table is
 
         rowid       Oid,          -- oid of our main data row         rowattno    int2,         -- the attribute
numberin main data         chunk_seq   int4,         -- the part number of this data chunk         chunk       text
    -- the content of this data chunk
 
I thought that there's an unique index (rowid,rowattno,chunk_seq).
Seems we could even update partially(specified chunk_seq only)
without problem.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp