← Back to branch summary

~vcs-imports/mammoth-replicator/trunk

« back to all changes in this revision

Viewing changes to src/include/catalog/catversion.h

  • Committer: alvherre
  • Date: 2005-12-16 21:24:52 UTC
  • Revision ID: svn-v4:db760fc0-0f08-0410-9d63-cc6633f64896:trunk:1
Initial import of the REL8_0_3 sources from the Pgsql CVS repository.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/include/catalog/catversion.h
 
1
/*-------------------------------------------------------------------------
 
2
 *
 
3
 * catversion.h
 
4
 *        "Catalog version number" for PostgreSQL.
 
5
 *
 
6
 * The catalog version number is used to flag incompatible changes in
 
7
 * the PostgreSQL system catalogs.      Whenever anyone changes the format of
 
8
 * a system catalog relation, or adds, deletes, or modifies standard
 
9
 * catalog entries in such a way that an updated backend wouldn't work
 
10
 * with an old database (or vice versa), the catalog version number
 
11
 * should be changed.  The version number stored in pg_control by initdb
 
12
 * is checked against the version number compiled into the backend at
 
13
 * startup time, so that a backend can refuse to run in an incompatible
 
14
 * database.
 
15
 *
 
16
 * The point of this feature is to provide a finer grain of compatibility
 
17
 * checking than is possible from looking at the major version number
 
18
 * stored in PG_VERSION.  It shouldn't matter to end users, but during
 
19
 * development cycles we usually make quite a few incompatible changes
 
20
 * to the contents of the system catalogs, and we don't want to bump the
 
21
 * major version number for each one.  What we can do instead is bump
 
22
 * this internal version number.  This should save some grief for
 
23
 * developers who might otherwise waste time tracking down "bugs" that
 
24
 * are really just code-vs-database incompatibilities.
 
25
 *
 
26
 * The rule for developers is: if you commit a change that requires
 
27
 * an initdb, you should update the catalog version number (as well as
 
28
 * notifying the pghackers mailing list, which has been the informal
 
29
 * practice for a long time).
 
30
 *
 
31
 * The catalog version number is placed here since modifying files in
 
32
 * include/catalog is the most common kind of initdb-forcing change.
 
33
 * But it could be used to protect any kind of incompatible change in
 
34
 * database contents or layout, such as altering tuple headers.
 
35
 *
 
36
 *
 
37
 * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
 
38
 * Portions Copyright (c) 1994, Regents of the University of California
 
39
 *
 
40
 * $PostgreSQL: pgsql/src/include/catalog/catversion.h,v 1.253 2004-12-31 22:03:24 pgsql Exp $
 
41
 *
 
42
 *-------------------------------------------------------------------------
 
43
 */
 
44
#ifndef CATVERSION_H
 
45
#define CATVERSION_H
 
46
 
 
47
/*
 
48
 * We could use anything we wanted for version numbers, but I recommend
 
49
 * following the "YYYYMMDDN" style often used for DNS zone serial numbers.
 
50
 * YYYYMMDD are the date of the change, and N is the number of the change
 
51
 * on that day.  (Hopefully we'll never commit ten independent sets of
 
52
 * catalog changes on the same day...)
 
53
 */
 
54
 
 
55
/*                                                      yyyymmddN */
 
56
#define CATALOG_VERSION_NO      200411041
 
57
 
 
58
#endif