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 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      202301232
  61
  62 #endif