PostgreSQL Source Code  git master
catversion.h
Go to the documentation of this file.
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 pgsql-hackers mailing list, which has been the
29  * informal 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  * Another common reason for a catversion update is a change in parsetree
36  * external representation, since serialized parsetrees appear in stored
37  * rules and new-style SQL functions. Almost any change in primnodes.h or
38  * parsenodes.h will warrant a catversion update.
39  *
40  *
41  * Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
42  * Portions Copyright (c) 1994, Regents of the University of California
43  *
44  * src/include/catalog/catversion.h
45  *
46  *-------------------------------------------------------------------------
47  */
48 #ifndef CATVERSION_H
49 #define CATVERSION_H
50 
51 /*
52  * We could use anything we wanted for version numbers, but I recommend
53  * following the "YYYYMMDDN" style often used for DNS zone serial numbers.
54  * YYYYMMDD are the date of the change, and N is the number of the change
55  * on that day. (Hopefully we'll never commit ten independent sets of
56  * catalog changes on the same day...)
57  */
58 
59 /* yyyymmddN */
60 #define CATALOG_VERSION_NO 202301301
61 
62 #endif