What changed?

8.2 → 8.3
+ amcanorder  boolean
+ amsearchnulls  boolean
- amorderstrategy  smallint

8.2 → 8.3
+ amopfamily  oid
+ amoplefttype  oid
+ amoprighttype  oid
+ amopmethod  oid
- amopclaid  oid
- amopsubtype  oid

8.2 → 8.3
+ amprocfamily  oid
+ amproclefttype  oid
+ amprocrighttype  oid
- amopclaid  oid
- amprocsubtype  oid

--- 8.2
+++ 8.3
@@ -6,7 +6,7 @@
 attlen: A copy of pg_type.typlen of this column's type
 attnum: The number of the column. Ordinary columns are numbered from 1 up. System columns, such as oid, have (arbitrary) negative numbers
 attndims: Number of dimensions, if the column is an array type; otherwise 0. (Presently, the number of dimensions of an array is not enforced, so any nonzero value effectively means "it's an array")
-attcacheoff: Always -1 in storage, but when loaded into a row descriptor in memory this may be updated to cache the offset of the attribute within the row
+attcacheoff: Always -1 in storage, but when loaded into a row descriptor in memory this might be updated to cache the offset of the attribute within the row
 atttypmod: atttypmod records type-specific data supplied at table creation time (for example, the maximum length of a varchar column). It is passed to type-specific input functions and length coercion functions. The value will generally be -1 for types that do not need atttypmod
 attbyval: A copy of pg_type.typbyval of this column's type
 attstorage: Normally a copy of pg_type.typstorage of this column's type. For TOAST-able data types, this can be altered after column creation to control storage policy
@@ -14,5 +14,5 @@
 attnotnull: This represents a not-null constraint. It is possible to change this column to enable or disable the constraint
 atthasdef: This column has a default value, in which case there will be a corresponding entry in the pg_attrdef catalog that actually defines the value
 attisdropped: This column has been dropped and is no longer valid. A dropped column is still physically present in the table, but is ignored by the parser and so cannot be accessed via SQL
-attislocal: This column is defined locally in the relation. Note that a column may be locally defined and inherited simultaneously
+attislocal: This column is defined locally in the relation. Note that a column can be locally defined and inherited simultaneously
 attinhcount: The number of direct ancestors this column has. A column with a nonzero number of ancestors cannot be dropped nor renamed

--- 8.2
+++ 8.3
@@ -2,4 +2,4 @@
 roleid: ID of a role that has a member
 member: ID of a role that is a member of roleid
 grantor: ID of the role that granted this membership
-admin_option: True if member may grant membership in roleid to others
+admin_option: True if member can grant membership in roleid to others

--- 8.2
+++ 8.3
@@ -1,11 +1,11 @@
-(relation) The catalog pg_authid contains information about database authorization identifiers (roles). A role subsumes the concepts of "users" and "groups". A user is essentially just a role with the rolcanlogin flag set. Any role (with or without rolcanlogin) may have other roles as members; see pg_auth_members. Since this catalog contains passwords, it must not be publicly readable. pg_roles is a publicly readable view on pg_authid that blanks out the password field. Chapter 18 contains detailed information about user and privilege management. Because user identities are cluster-wide, pg_authid is shared across all databases of a cluster: there is only one copy of pg_authid per cluster, not one per database.
+(relation) The catalog pg_authid contains information about database authorization identifiers (roles). A role subsumes the concepts of "users" and "groups". A user is essentially just a role with the rolcanlogin flag set. Any role (with or without rolcanlogin) can have other roles as members; see pg_auth_members. Since this catalog contains passwords, it must not be publicly readable. pg_roles is a publicly readable view on pg_authid that blanks out the password field. Chapter 19 contains detailed information about user and privilege management. Because user identities are cluster-wide, pg_authid is shared across all databases of a cluster: there is only one copy of pg_authid per cluster, not one per database.
 rolname: Role name
 rolsuper: Role has superuser privileges
 rolinherit: Role automatically inherits privileges of roles it is a member of
-rolcreaterole: Role may create more roles
-rolcreatedb: Role may create databases
-rolcatupdate: Role may update system catalogs directly. (Even a superuser may not do this unless this column is true)
-rolcanlogin: Role may log in. That is, this role can be given as the initial session authorization identifier
+rolcreaterole: Role can create more roles
+rolcreatedb: Role can create databases
+rolcatupdate: Role can update system catalogs directly. (Even a superuser cannot do this unless this column is true)
+rolcanlogin: Role can log in. That is, this role can be given as the initial session authorization identifier
 rolconnlimit: For roles that can log in, this sets maximum number of concurrent connections this role can make. -1 means no limit
 rolpassword: Password (possibly encrypted); NULL if none
 rolvaliduntil: Password expiry time (only used for password authentication); NULL if no expiration

--- 8.2
+++ 8.3
@@ -1,4 +1,4 @@
-(relation) The catalog pg_autovacuum stores optional per-relation configuration parameters for the autovacuum daemon. If there is an entry here for a particular relation, the given parameters will be used for autovacuuming that table. If no entry is present, the system-wide defaults will be used. For more information about the autovacuum daemon, see Section 22.1.4.
+(relation) The catalog pg_autovacuum stores optional per-relation configuration parameters for the autovacuum daemon. If there is an entry here for a particular relation, the given parameters will be used for autovacuuming that table. If no entry is present, the system-wide defaults will be used. For more information about the autovacuum daemon, see Section 23.1.4.
 vacrelid: The table this entry is for
 enabled: If false, this table will not be autovacuumed, except to prevent transaction ID wraparound
 vac_base_thresh: Minimum number of modified tuples before vacuum

--- 8.2
+++ 8.3
@@ -1,5 +1,5 @@
-(relation) The catalog pg_cast stores data type conversion paths, both built-in paths and those defined with CREATE CAST.
+(relation) The catalog pg_cast stores data type conversion paths, both built-in paths and those defined with CREATE CAST. It should be noted that pg_cast does not represent every type conversion that the system knows how to perform; only those that cannot be deduced from some generic rule. For example, casting between a domain and its base type is not explicitly represented in pg_cast. Another important exception is that "I/O conversion casts", those performed using a data type's own I/O functions to convert to or from text or other string types, are not explicitly represented in pg_cast.
 castsource: OID of the source data type
 casttarget: OID of the target data type
 castfunc: The OID of the function to use to perform this cast. Zero is stored if the data types are binary compatible (that is, no run-time operation is needed to perform the cast)
-castcontext: Indicates what contexts the cast may be invoked in. e means only as an explicit cast (using CAST or :: syntax). a means implicitly in assignment to a target column, as well as explicitly. i means implicitly in expressions, as well as the other cases
+castcontext: Indicates what contexts the cast can be invoked in. e means only as an explicit cast (using CAST or :: syntax). a means implicitly in assignment to a target column, as well as explicitly. i means implicitly in expressions, as well as the other cases

8.2 → 8.3
+ conpfeqop  oid[]
+ conppeqop  oid[]
+ conffeqop  oid[]

--- 8.2
+++ 8.3
@@ -1,4 +1,4 @@
-(relation) The pg_cursors view lists the cursors that are currently available. Cursors can be defined in several ways: via the DECLARE statement in SQL via the Bind message in the frontend/backend protocol, as described in Section 44.2.3 via the Server Programming Interface (SPI), as described in Section 41.1 The pg_cursors view displays cursors created by any of these means. Cursors only exist for the duration of the transaction that defines them, unless they have been declared WITH HOLD. Therefore non-holdable cursors are only present in the view until the end of their creating transaction.
+(relation) The pg_cursors view lists the cursors that are currently available. Cursors can be defined in several ways: via the DECLARE statement in SQL via the Bind message in the frontend/backend protocol, as described in Section 45.2.3 via the Server Programming Interface (SPI), as described in Section 42.1 The pg_cursors view displays cursors created by any of these means. Cursors only exist for the duration of the transaction that defines them, unless they have been declared WITH HOLD. Therefore non-holdable cursors are only present in the view until the end of their creating transaction.
 name: The name of the cursor
 statement: The verbatim query string submitted to declare this cursor
 is_holdable: true if the cursor is holdable (that is, it can be accessed after the transaction that declared the cursor has committed); false otherwise

--- 8.2
+++ 8.3
@@ -1,4 +1,4 @@
-(relation) The catalog pg_database stores information about the available databases. Databases are created with the CREATE DATABASE command. Consult Chapter 19 for details about the meaning of some of the parameters. Unlike most system catalogs, pg_database is shared across all databases of a cluster: there is only one copy of pg_database per cluster, not one per database.
+(relation) The catalog pg_database stores information about the available databases. Databases are created with the CREATE DATABASE command. Consult Chapter 20 for details about the meaning of some of the parameters. Unlike most system catalogs, pg_database is shared across all databases of a cluster: there is only one copy of pg_database per cluster, not one per database.
 datname: Database name
 datdba: Owner of the database, usually the user who created it
 encoding: Character encoding for this database (pg_encoding_to_char() can translate this number to the encoding name)

--- 8.2
+++ 8.3
@@ -0,0 +1,2 @@
+enumtypid  oid
+enumlabel  name

8.2 → 8.3
+ indcheckxmin  boolean
+ indisready  boolean
+ indoption  int2vector

8.2 → 8.3
+ lanowner  oid

--- 8.2
+++ 8.3
@@ -1,4 +1,4 @@
 (relation) The catalog pg_largeobject holds the data making up "large objects". A large object is identified by an OID assigned when it is created. Each large object is broken into segments or "pages" small enough to be conveniently stored as rows in pg_largeobject. The amount of data per page is defined to be LOBLKSIZE (which is currently BLCKSZ/4, or typically 2 kB).
 loid: Identifier of the large object that includes this page
 pageno: Page number of this page within its large object (counting from zero)
-data: Actual data stored in the large object. This will never be more than LOBLKSIZE bytes and may be less
+data: Actual data stored in the large object. This will never be more than LOBLKSIZE bytes and might be less

8.2 → 8.3
+ virtualxid  text
+ virtualtransaction  text
- transaction  xid

8.2 → 8.3
+ opcmethod  oid
+ opcfamily  oid
- opcamid  oid

8.2 → 8.3
+ oprcanmerge  boolean
- oprlsortop  oid
- oprrsortop  oid
- oprltcmpop  oid
- oprgtcmpop  oid

--- 8.2
+++ 8.3
@@ -0,0 +1,4 @@
+opfmethod  oid
+opfname  name
+opfnamespace  oid
+opfowner  oid

8.2 → 8.3
+ tmpldbacreate  boolean

8.2 → 8.3
+ procost  real
+ prorows  real
+ proconfig  text[]

8.2 → 8.3
+ ev_enabled  "char"

--- 8.2
+++ 8.3
@@ -2,10 +2,10 @@
 rolname: Role name
 rolsuper: Role has superuser privileges
 rolinherit: Role automatically inherits privileges of roles it is a member of
-rolcreaterole: Role may create more roles
-rolcreatedb: Role may create databases
-rolcatupdate: Role may update system catalogs directly. (Even a superuser may not do this unless this column is true.)
-rolcanlogin: Role may log in. That is, this role can be given as the initial session authorization identifier
+rolcreaterole: Role can create more roles
+rolcreatedb: Role can create databases
+rolcatupdate: Role can update system catalogs directly. (Even a superuser cannot do this unless this column is true.)
+rolcanlogin: Role can log in. That is, this role can be given as the initial session authorization identifier
 rolconnlimit: For roles that can log in, this sets maximum number of concurrent connections this role can make. -1 means no limit
 rolpassword: Not the password (always reads as ********)
 rolvaliduntil: Password expiry time (only used for password authentication); NULL if no expiration

--- 8.2
+++ 8.3
@@ -1,9 +1,9 @@
 (relation) The view pg_shadow exists for backwards compatibility: it emulates a catalog that existed in PostgreSQL before version 8.1. It shows properties of all roles that are marked as rolcanlogin. The name stems from the fact that this table should not be readable by the public since it contains passwords. pg_user is a publicly readable view on pg_shadow that blanks out the password field.
 usename: User name
 usesysid: ID of this user
-usecreatedb: User may create databases
+usecreatedb: User can create databases
 usesuper: User is a superuser
-usecatupd: User may update system catalogs. (Even a superuser may not do this unless this column is true.)
+usecatupd: User can update system catalogs. (Even a superuser cannot do this unless this column is true.)
 passwd: Password (possibly encrypted)
 valuntil: Password expiry time (only used for password authentication)
 useconfig: Session defaults for run-time configuration variables

--- 8.2
+++ 8.3
@@ -1 +1 @@
-(relation) One row per server process, showing database OID, database name, process ID, user OID, user name, current query, query's waiting status, time at which the current query began execution, time at which the process was started, and client's address and port number. The columns that report data on the current query are available unless the parameter stats_command_string has been turned off. Furthermore, these columns are only visible if the user examining the view is a superuser or the same as the user owning the process being reported on.
+(relation) One row per server process, showing database OID, database name, process ID, user OID, user name, current query, query's waiting status, time at which the current transaction and current query began execution, time at which the process was started, and client's address and port number. The columns that report data on the current query are available unless the parameter track_activities has been turned off. Furthermore, these columns are only visible if the user examining the view is a superuser or the same as the user owning the process being reported on.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-(relation) For each table in the current database (including TOAST tables), the table OID, schema and table name, number of sequential scans initiated, number of live rows fetched by sequential scans, number of index scans initiated (over all indexes belonging to the table), number of live rows fetched by index scans, numbers of row insertions, updates, and deletions, the last time the table was vacuumed manually, the last time it was vacuumed by the autovacuum daemon, the last time it was analyzed manually, and the last time it was analyzed by the autovacuum daemon.
+(relation) For each table in the current database (including TOAST tables), the table OID, schema and table name, number of sequential scans initiated, number of live rows fetched by sequential scans, number of index scans initiated (over all indexes belonging to the table), number of live rows fetched by index scans, numbers of row insertions, updates, and deletions, number of row updates that were HOT (i.e., no separate index update), numbers of live and dead rows, the last time the table was vacuumed manually, the last time it was vacuumed by the autovacuum daemon, the last time it was analyzed manually, and the last time it was analyzed by the autovacuum daemon.

This manual names the view without listing its columns.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-(relation) One row per database, showing database OID, database name, number of active server processes connected to that database, number of transactions committed and rolled back in that database, total disk blocks read, and total buffer hits (i.e., block read requests avoided by finding the block already in buffer cache).
+(relation) One row per database, showing database OID, database name, number of active server processes connected to that database, number of transactions committed and rolled back in that database, total disk blocks read, total buffer hits (i.e., block read requests avoided by finding the block already in buffer cache), number of rows returned, fetched, inserted, updated and deleted.

--- 8.2
+++ 8.3
@@ -1,4 +1,4 @@
-(relation) The catalog pg_statistic stores statistical data about the contents of the database. Entries are created by ANALYZE and subsequently used by the query planner. There is one entry for each table column that has been analyzed. Note that all the statistical data is inherently approximate, even assuming that it is up-to-date. pg_statistic also stores statistical data about the values of index expressions. These are described as if they were actual data columns; in particular, starelid references the index. No entry is made for an ordinary non-expression index column, however, since it would be redundant with the entry for the underlying table column. Since different kinds of statistics may be appropriate for different kinds of data, pg_statistic is designed not to assume very much about what sort of statistics it stores. Only extremely general statistics (such as nullness) are given dedicated columns in pg_statistic. Everything else is stored in "slots", which are groups of associated columns whose content is identified by a code number in one of the slot's columns. For more information see src/include/catalog/pg_statistic.h. pg_statistic should not be readable by the public, since even statistical information about a table's contents may be considered sensitive. (Example: minimum and maximum values of a salary column might be quite interesting.) pg_stats is a publicly readable view on pg_statistic that only exposes information about those tables that are readable by the current user.
+(relation) The catalog pg_statistic stores statistical data about the contents of the database. Entries are created by ANALYZE and subsequently used by the query planner. There is one entry for each table column that has been analyzed. Note that all the statistical data is inherently approximate, even assuming that it is up-to-date. pg_statistic also stores statistical data about the values of index expressions. These are described as if they were actual data columns; in particular, starelid references the index. No entry is made for an ordinary non-expression index column, however, since it would be redundant with the entry for the underlying table column. Since different kinds of statistics might be appropriate for different kinds of data, pg_statistic is designed not to assume very much about what sort of statistics it stores. Only extremely general statistics (such as nullness) are given dedicated columns in pg_statistic. Everything else is stored in "slots", which are groups of associated columns whose content is identified by a code number in one of the slot's columns. For more information see src/include/catalog/pg_statistic.h. pg_statistic should not be readable by the public, since even statistical information about a table's contents might be considered sensitive. (Example: minimum and maximum values of a salary column might be quite interesting.) pg_stats is a publicly readable view on pg_statistic that only exposes information about those tables that are readable by the current user.
 starelid: The table or index that the described column belongs to
 staattnum: The number of the described column
 stanullfrac: The fraction of the column's entries that are null

8.2 → 8.3
+ tgconstraint  oid
~ tgenabled  boolean → "char"

--- 8.2
+++ 8.3
@@ -0,0 +1,4 @@
+cfgname  name
+cfgnamespace  oid
+cfgowner  oid
+cfgparser  oid

--- 8.2
+++ 8.3
@@ -0,0 +1,4 @@
+mapcfg  oid
+maptokentype  integer
+mapseqno  integer
+mapdict  oid

--- 8.2
+++ 8.3
@@ -0,0 +1,5 @@
+dictname  name
+dictnamespace  oid
+dictowner  oid
+dicttemplate  oid
+dictinitoption  text

--- 8.2
+++ 8.3
@@ -0,0 +1,7 @@
+prsname  name
+prsnamespace  oid
+prsstart  regproc
+prstoken  regproc
+prsend  regproc
+prsheadline  regproc
+prslextype  regproc

--- 8.2
+++ 8.3
@@ -0,0 +1,4 @@
+tmplname  name
+tmplnamespace  oid
+tmplinit  regproc
+tmpllexize  regproc

8.2 → 8.3
+ typarray  oid
+ typmodin  regproc
+ typmodout  regproc

--- 8.2
+++ 8.3
@@ -1,9 +1,9 @@
 (relation) The view pg_user provides access to information about database users. This is simply a publicly readable view of pg_shadow that blanks out the password field.
 usename: User name
 usesysid: User ID (arbitrary number used to reference this user)
-usecreatedb: User may create databases
+usecreatedb: User can create databases
 usesuper: User is a superuser
-usecatupd: User may update system catalogs. (Even a superuser may not do this unless this column is true.)
+usecatupd: User can update system catalogs. (Even a superuser cannot do this unless this column is true.)
 passwd: Not the password (always reads as ********)
 valuntil: Password expiry time (only used for password authentication)
 useconfig: Session defaults for run-time configuration variables