postgresql/src/include/catalog/catversion.h
Tom Lane 5ebaaa4944 Implement SQL-standard LATERAL subqueries.
This patch implements the standard syntax of LATERAL attached to a
sub-SELECT in FROM, and also allows LATERAL attached to a function in FROM,
since set-returning function calls are expected to be one of the principal
use-cases.

The main change here is a rewrite of the mechanism for keeping track of
which relations are visible for column references while the FROM clause is
being scanned.  The parser "namespace" lists are no longer lists of bare
RTEs, but are lists of ParseNamespaceItem structs, which carry an RTE
pointer as well as some visibility-controlling flags.  Aside from
supporting LATERAL correctly, this lets us get rid of the ancient hacks
that required rechecking subqueries and JOIN/ON and function-in-FROM
expressions for invalid references after they were initially parsed.
Invalid column references are now always correctly detected on sight.

In passing, remove assorted parser error checks that are now dead code by
virtue of our having gotten rid of add_missing_from, as well as some
comments that are obsolete for the same reason.  (It was mainly
add_missing_from that caused so much fudging here in the first place.)

The planner support for this feature is very minimal, and will be improved
in future patches.  It works well enough for testing purposes, though.

catversion bump forced due to new field in RangeTblEntry.
2012-08-07 19:02:54 -04:00

58 lines
2.5 KiB
C

/*-------------------------------------------------------------------------
*
* 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-2012, 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 201208071
#endif