init
This commit is contained in:
58
db_include/catalog/catversion.h
Executable file
58
db_include/catalog/catversion.h
Executable file
@@ -0,0 +1,58 @@
|
||||
/*-------------------------------------------------------------------------
|
||||
*
|
||||
* 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.
|
||||
*
|
||||
*
|
||||
* Portions Copyright (c) 1996-2021, 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 202107181
|
||||
|
||||
#endif
|
||||
Reference in New Issue
Block a user