Re: include/commands/version.h is not used - Mailing list pgsql-hackers

From Tom Lane
Subject Re: include/commands/version.h is not used
Date
Msg-id 20384.1249655792@sss.pgh.pa.us
Whole thread Raw
In response to Re: include/commands/version.h is not used  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Aug 7, 2009 at 05:04, Itagaki
> Takahiro<itagaki.takahiro@oss.ntt.co.jp> wrote:
>> I found include/commands/version.h is empty and not included from any files.
>> What is the purpose of the file?

>> From what I can tell, it hasn't been used since back in the Berkeley
> days, but it did contain some function headers that were removed back
> in 1997. I think we can just get rid of it...

+1.  Looking at the postgres v4r2 sources, it was for their "version"
facility, which evidently got ripped out later.  The description in the
create_version man page is interesting:

This command creates a version class
.IR classname1
which is related
to its parent class,
.IR classname2 .
Initially,
.IR classname1
has the same contents as
.IR classname2.
As updates to 
.IR classname1 
occur, however,
the content of
.IR classname1
diverges from
.IR classname2.
On the other hand, any updates to
.IR classname2
show transparently through to
.IR classname1 ,
unless the instance in question has already been updated in
.IR classname1 .  
.PP
If the optional
.IR abstime
clause is specified, then the version is constructed relative to a
.BR snapshot
of
.IR classname2
as of the time specified.
.PP
\*(PG uses the query rewrite rule system to ensure that 
.IR classname1
is differentially encoded relative to
.IR classname2.  
Moreover, 
.IR classname1
is automatically constructed to have the same indexes as
.IR classname2 .
It is legal to cascade versions arbitrarily, so a tree of versions can
ultimately result.  The algorithms that control versions are explained
in [ONG90].

So that appears to depend on time travel, and also on a version of query
rewrite rules that we no longer have.  Dead as a doornail :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: Sam Mason
Date:
Subject: Re: Table and Index compression
Next
From: Kenneth Marshall
Date:
Subject: Re: Fixing geometic calculation