Subject: Inversion Files...

From: [email-masked]
Date: Tue, 25 Jan 1994 09:51:41 +0800

I have some conceptual questions about the Inversion Filesystem.

If I set up a class that has a Inversion file as an attribute ala

create File 
(
   name = text,
   ifile = InvFile
) \g

My I/O functions inv_file_in and inv_file_out do the following

inv_file_in 
   Check for inversion file's existance with LOstat();
   If it doesn't exist: 
      LOcreat(fName, INV_READ|INV_WRITE|INV_ARCHIVE, Inversion).
      read from a unix file, write to the inversion file.
      close both files.
      Fill my IFile struct (varlena) and return.
   If it does exist, fill my IFile struct (varlena), and return;

inv_file_out
   return the name component of my IFile struct

I also defined a function inv_file_eq() which compares the names of
two files for equality.

Now, some questions...

   When I append new touples to the table, a new inversion file
   is created on the system. I can see these files with 
   $POSTGRESHOME/bin/pls. I added the LOstat call to inv_file_in
   because it is called when I test for equality, and I can't recreate
   the file (nor would I want to). Is this reasonable?

   Next, I can do historical queries on this table, and see all versions
   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.

   How do I do the same thing from libpq?

   I'd also be interested to hear how people who have used the inversion
   file system have set up their tables and input/output routines to support
   their conceptual models...

   Perhaps I'm just confused about how Inversion file are supposed to be used?

   Thanks,
   Frank
+--------------------------------------+--------------------------------------+
|Frank M. Goodman                      |         Trillium Digital Systems Inc.|
[email-masked]                |       2001 S. Barrington Ave, Ste 215| 
|Ph: 310 479-0500, Fax: 310 575-0172   |         Los Angeles, California 90025|
+--------------------------------------+--------------------------------------+

---

From: [email-masked] (Paul M. Aoki)
Date: Tue, 25 Jan 1994 15:50:43 -0800

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

>    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  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki