/*------------------------------------------------------------------------- * * 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 - 2025 , 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 202506291 #endif
Messung V0.5 in Prozent C=93 H=95 G=93
¤ Dauer der Verarbeitung: 0.10 Sekunden
(vorverarbeitet am 2026-08-08)
¤ *© Formatika GbR, Deutschland
