codekingpro/portable-devtools

1/*-------------------------------------------------------------------------2 *3 * catversion.h4 *	  "Catalog version number" for PostgreSQL.5 *6 * The catalog version number is used to flag incompatible changes in7 * the PostgreSQL system catalogs.  Whenever anyone changes the format of8 * a system catalog relation, or adds, deletes, or modifies standard9 * catalog entries in such a way that an updated backend wouldn't work10 * with an old database (or vice versa), the catalog version number11 * should be changed.  The version number stored in pg_control by initdb12 * is checked against the version number compiled into the backend at13 * startup time, so that a backend can refuse to run in an incompatible14 * database.15 *16 * The point of this feature is to provide a finer grain of compatibility17 * checking than is possible from looking at the major version number18 * stored in PG_VERSION.  It shouldn't matter to end users, but during19 * development cycles we usually make quite a few incompatible changes20 * to the contents of the system catalogs, and we don't want to bump the21 * major version number for each one.  What we can do instead is bump22 * this internal version number.  This should save some grief for23 * developers who might otherwise waste time tracking down "bugs" that24 * are really just code-vs-database incompatibilities.25 *26 * The rule for developers is: if you commit a change that requires27 * an initdb, you should update the catalog version number (as well as28 * notifying the pgsql-hackers mailing list, which has been the29 * informal practice for a long time).30 *31 * The catalog version number is placed here since modifying files in32 * include/catalog is the most common kind of initdb-forcing change.33 * But it could be used to protect any kind of incompatible change in34 * database contents or layout, such as altering tuple headers.35 * Another common reason for a catversion update is a change in parsetree36 * external representation, since serialized parsetrees appear in stored37 * rules and new-style SQL functions.  Almost any change in primnodes.h or38 * parsenodes.h will warrant a catversion update.39 *40 *41 * Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group42 * Portions Copyright (c) 1994, Regents of the University of California43 *44 * src/include/catalog/catversion.h45 *46 *-------------------------------------------------------------------------47 */48#ifndef CATVERSION_H49#define CATVERSION_H50 51/*52 * We could use anything we wanted for version numbers, but I recommend53 * 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 change55 * on that day.  (Hopefully we'll never commit ten independent sets of56 * catalog changes on the same day...)57 */58 59/*							yyyymmddN */60#define CATALOG_VERSION_NO	20230707161 62#endif63