Adding upstream version 16.2.upstream/16.2

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 62 insertions, 0 deletions

diff --git a/src/include/catalog/catversion.h b/src/include/catalog/catversion.h
new file mode 100644
index 0000000..cc1de6e
--- /dev/null
+++ b/src/include/catalog/catversion.h
@@ -0,0 +1,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