| /*------------------------------------------------------------------------- |
| * |
| * 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 pghackers 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-2009, PostgreSQL Global Development Group |
| * Portions Copyright (c) 1994, Regents of the University of California |
| * |
| * $PostgreSQL: pgsql/src/include/catalog/catversion.h,v 1.531 2009/06/11 14:49:09 momjian Exp $ |
| * |
| *------------------------------------------------------------------------- |
| */ |
| #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 201507221 |
| |
| #endif |