Re: [HACKERS] LONG

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Jan Wieck <wieck@debis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Date: 1999-12-13T02:38:15Z
Lists: pgsql-hackers
>     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.

Having a separate oid for the long value is great.  You can then have
multiple versions of the long attribute in the long table and can
control when updating a tuple.

I liked Hiroshi's idea of allowing long values in an index by just
pointing to the long table.  Seems that would work too.  varlena access
routines make that possible.



-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026