1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
/*-------------------------------------------------------------------------
*
* catversion.h
* "Catalog version number" for PostgreSQL.
*
* The catalog version number is used to flag incompatible changes in
* the PostgreSQL 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 pgsql-hackers 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.
* Another common reason for a catversion update is a change in parsetree
* external representation, since serialized parsetrees appear in stored
* rules and new-style SQL functions. Almost any change in primnodes.h or
* parsenodes.h will warrant a catversion update.
*
*
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* src/include/catalog/catversion.h
*
*-------------------------------------------------------------------------
*/
#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...)
*/
/* yyyymmddN */
#define CATALOG_VERSION_NO 202307071
#endif
|
