> -----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