Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199401252350.PAA02845@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199401252350.PAA05165@heel.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: fmg@trillium.com
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: Inversion Files... 
In-reply-to: Your message of Tue, 25 Jan 1994 09:51:41 +0800 
	     <9401251751.AA02061@trillium.com> 
Date: Tue, 25 Jan 1994 15:50:43 -0800
Resent-To: postgres-dist@postgres.Berkeley.EDU
Resent-Date: Tue, 25 Jan 94 15:50:56 -0800
Resent-XMts: smtp

i'll let other people comment on your other points, but..

fmg@trillium.com writes:
>    of the table over time as I append and replace touples. Now, how do
>    I retrieve an old version of the actual inversion file itself rather
>    than its representation in the table which is merely its name, and may
>    be the same at different time though the contents may be different.

if the large object is a Unix large object (created with p_creat and
the Unix flag), there's no time travel capability on the file contents 
at all because it's, well, a unix file. :-)

if the large object is an inversion large object (created with p_creat
and the Inversion flag), the only way to get at its content history is 
to realize that
	1. the large object is stored as instances in a class (with an
	incomprehensible name generated from the large object oid)
	2. the instances that are valid at a given time form a snapshot
	of the bits in the file
	3. you can assemble the bits in the right order using queries
	and binary portals
because there is no way from the inversion file API to pass in a time
qualification to the code that assembles the bits for you when you do 
p_read, p_write, etc.  it always gets the latest contents of the file.

this means that time travel on the actual contents of an inversion
large object is very, very hard to do -- though theoretically possible.

there is the additional complication that the implementation of the
inversion large objects does not correctly support overwriting of
the contents anyway.  some people have correctly noted that re-writing
into an inversion large object (as opposed to a unix large object) 
does not, in general, work.  (i was working on this for a while but
i don't know if i'm going to have the time to finish it.)  for now, i'd
have to say, "don't do that."
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki