Re: [HACKERS] LONG

>     I  thought  to  use  a  regular table. Of course, it will eat
>     buffers, but managing external files or  even  large  objects
>     for  it  IMHO  isn't  that  simple,  if  you take transaction
>     commit/abort and MVCC problematic into account too. And  IMHO
>     this  is  something  that must be covered, because I meant to
>     create a DATATYPE that can be used as a replacement for  TEXT
>     if that's too small, so it must behave as a regular datatype,
>     without any restrictions WRT beeing able to rollback etc.

In fact, you could get fancy and allow an update of a non-pg_long using
column to not change pg_long at all.  Just keep the same value in the
column.  If the transaction fails or succeeds, the pg_long is the same
for that tuple.  Of course, because an update is a delete and then an
insert, that may be hard to do.  For very long fields, it would be a win
for UPDATE.  You certainly couldn't do that with chained tuples.

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