2000-04-12 19:17:23 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
* catversion.h
|
2003-01-24 00:39:07 +01:00
|
|
|
* "Catalog version number" for PostgreSQL.
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
* The catalog version number is used to flag incompatible changes in
|
2014-05-06 18:12:18 +02:00
|
|
|
* the PostgreSQL system catalogs. Whenever anyone changes the format of
|
1999-10-24 22:42:27 +02:00
|
|
|
* 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
|
2019-08-05 05:14:58 +02:00
|
|
|
* notifying the pgsql-hackers mailing list, which has been the
|
|
|
|
* informal practice for a long time).
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/catversion.h
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#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...)
|
|
|
|
*/
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* yyyymmddN */
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
#define CATALOG_VERSION_NO 202009172
|
2001-10-28 07:26:15 +01:00
|
|
|
|
1999-10-24 22:42:27 +02:00
|
|
|
#endif
|