RE: [HACKERS] LONG

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)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 need it.
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 number in 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(at)tpf(dot)co(dot)jp