mirror of https://github.com/postgres/postgres
when an initdb-forcing change has been applied within a development cycle. PG_VERSION serves this purpose for official releases, but we can't bump the PG_VERSION number every time we make a change to the catalogs during development. Instead, increase the catalog version number to warn other developers that you've made an incompatible change. See my mail to pghackers for more info.REL7_0_PATCHES
parent
9efee18a28
commit
eae456cd7f
@ -0,0 +1,56 @@ |
|||||||
|
/*-------------------------------------------------------------------------
|
||||||
|
* |
||||||
|
* catversion.h |
||||||
|
* "Catalog version number" for Postgres. |
||||||
|
* |
||||||
|
* The catalog version number is used to flag incompatible changes in |
||||||
|
* the Postgres system catalogs. Whenever anyone changes the format of |
||||||
|
* a system catalog relation, or adds, deletes, or modifies standard |
||||||
|
* catalog entries in such a way that an updated backend wouldn't work |
||||||
|
* with an old database (or vice versa), the catalog version number |
||||||
|
* should be changed. The version number stored in pg_control by initdb |
||||||
|
* is checked against the version number compiled into the backend at |
||||||
|
* startup time, so that a backend can refuse to run in an incompatible |
||||||
|
* database. |
||||||
|
* |
||||||
|
* The point of this feature is to provide a finer grain of compatibility |
||||||
|
* checking than is possible from looking at the major version number |
||||||
|
* stored in PG_VERSION. It shouldn't matter to end users, but during |
||||||
|
* development cycles we usually make quite a few incompatible changes |
||||||
|
* to the contents of the system catalogs, and we don't want to bump the |
||||||
|
* major version number for each one. What we can do instead is bump |
||||||
|
* this internal version number. This should save some grief for |
||||||
|
* developers who might otherwise waste time tracking down "bugs" that |
||||||
|
* are really just code-vs-database incompatibilities. |
||||||
|
* |
||||||
|
* The rule for developers is: if you commit a change that requires |
||||||
|
* an initdb, you should update the catalog version number (as well as |
||||||
|
* notifying the pghackers mailing list, which has been the informal |
||||||
|
* practice for a long time). |
||||||
|
* |
||||||
|
* The catalog version number is placed here since modifying files in |
||||||
|
* include/catalog is the most common kind of initdb-forcing change. |
||||||
|
* But it could be used to protect any kind of incompatible change in |
||||||
|
* database contents or layout, such as altering tuple headers. |
||||||
|
* |
||||||
|
* |
||||||
|
* Copyright (c) 1994, Regents of the University of California |
||||||
|
* |
||||||
|
* $Id: catversion.h,v 1.1 1999/10/24 20:42:26 tgl Exp $ |
||||||
|
* |
||||||
|
*------------------------------------------------------------------------- |
||||||
|
*/ |
||||||
|
#ifndef CATVERSION_H |
||||||
|
#define CATVERSION_H |
||||||
|
|
||||||
|
/*
|
||||||
|
* We could use anything we wanted for version numbers, but I recommend |
||||||
|
* following the "YYYYMMDDN" style often used for DNS zone serial numbers. |
||||||
|
* YYYYMMDD are the date of the change, and N is the number of the change |
||||||
|
* on that day. (Hopefully we'll never commit ten independent sets of |
||||||
|
* catalog changes on the same day...) |
||||||
|
*/ |
||||||
|
|
||||||
|
#define CATALOG_VERSION_NO 199910241 |
||||||
|
|
||||||
|
#endif |
Loading…
Reference in new issue