| 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-2019, PostgreSQL Global Development Group |
| 38 | * Portions Copyright (c) 1994, Regents of the University of California |
| 39 | * |
| 40 | * src/include/catalog/catversion.h |
| 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 201909212 |
| 57 | |
| 58 | #endif |
| 59 | |