What changed?

9.5 → 9.6
+ aggcombinefn  regproc
+ aggserialfn  regproc
+ aggdeserialfn  regproc

9.5 → 9.6
+ amhandler  regproc
+ amtype  "char"
- amstrategies  smallint
- amsupport  smallint
- amcanorder  boolean
- amcanorderbyop  boolean
- amcanbackward  boolean
- amcanunique  boolean
- amcanmulticol  boolean
- amoptionalkey  boolean
- amsearcharray  boolean
- amsearchnulls  boolean
- amstorage  boolean
- amclusterable  boolean
- ampredlocks  boolean
- amkeytype  oid
- aminsert  regproc
- ambeginscan  regproc
- amgettuple  regproc
- amgetbitmap  regproc
- amrescan  regproc
- amendscan  regproc
- ammarkpos  regproc
- amrestrpos  regproc
- ambuild  regproc
- ambuildempty  regproc
- ambulkdelete  regproc
- amvacuumcleanup  regproc
- amcanreturn  regproc
- amcostestimate  regproc
- amoptions  regproc

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(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 20 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 21 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.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 rolname: Role name
 rolsuper: Role has superuser privileges
@@ -6,7 +6,7 @@
 rolcreaterole: Role can create more roles
 rolcreatedb: Role can create databases
 rolcanlogin: Role can log in. That is, this role can be given as the initial session authorization identifier.
-rolreplication: Role is a replication role. That is, this role can initiate streaming replication (see Section 25.2.5) and set/unset the system backup mode using pg_start_backup and pg_stop_backup
+rolreplication: Role is a replication role. A replication role can initiate replication connections and create and drop replication slots.
 rolbypassrls: Role bypasses every row level security policy, see Section 5.7 for more information.
 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. If the password is encrypted, this column will begin with the string md5 followed by a 32-character hexadecimal MD5 hash. The MD5 hash will be of the user's password concatenated to their user name. For example, if user joe has password xyzzy, PostgreSQL will store the md5 hash of xyzzyjoe. A password that does not follow that format is assumed to be unencrypted.

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_collation describes the available collations, which are essentially mappings from an SQL name to operating system locale categories. See Section 22.2 for more information.
+(relation) The catalog pg_collation describes the available collations, which are essentially mappings from an SQL name to operating system locale categories. See Section 23.2 for more information.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 collname: Collation name (unique per namespace and encoding)
 collnamespace: The OID of the namespace that contains this collation

--- 9.5
+++ 9.6
@@ -0,0 +1,2 @@
+name  text
+setting  text

--- 9.5
+++ 9.6
@@ -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 50.2.3 via the Server Programming Interface (SPI), as described in Section 44.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 51.2.3 via the Server Programming Interface (SPI), as described in Section 45.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

--- 9.5
+++ 9.6
@@ -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 21 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 22 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.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 datname: Database name
 datdba: Owner of the database, usually the user who created it

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_event_trigger stores event triggers. See Chapter 37 for more information.
+(relation) The catalog pg_event_trigger stores event triggers. See Chapter 38 for more information.
 evtname: Trigger name (must be unique)
 evtevent: Identifies the event for which this trigger fires
 evtowner: Owner of the event trigger

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_extension stores information about the installed extensions. See Section 35.15 for details about extensions.
+(relation) The catalog pg_extension stores information about the installed extensions. See Section 36.15 for details about extensions.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 extname: Name of the extension
 extowner: Owner of the extension

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The view pg_file_settings provides a summary of the contents of the server's configuration file(s). A row appears in this view for each "name = value" entry appearing in the files, with annotations indicating whether the value could be applied successfully. Additional row(s) may appear for problems not linked to a "name = value" entry, such as syntax errors in the files. This view is helpful for checking whether planned changes in the configuration files will work, or for diagnosing a previous failure. Note that this view reports on the current contents of the files, not on what was last applied by the server. (The pg_settings view is usually sufficient to determine that.) The pg_file_settings view can be read only by superusers.
+(relation) The view pg_file_settings provides a summary of the contents of the server's configuration file(s). A row appears in this view for each "name = value" entry appearing in the files, with annotations indicating whether the value could be applied successfully. Additional row(s) may appear for problems not linked to a "name = value" entry, such as syntax errors in the files. This view is helpful for checking whether planned changes in the configuration files will work, or for diagnosing a previous failure. Note that this view reports on the current contents of the files, not on what was last applied by the server. (The pg_settings view is usually sufficient to determine that.) By default, the pg_file_settings view can be read only by superusers.
 sourcefile: Full path name of the configuration file
 sourceline: Line number within the configuration file where the entry appears
 seqno: Order in which the entries are processed (1..n)

--- 9.5
+++ 9.6
@@ -0,0 +1,5 @@
+objoid  oid
+classoid  oid
+objsubid  integer
+privtype  "char"
+initprivs  aclitem[]

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_language registers languages in which you can write functions or stored procedures. See CREATE LANGUAGE and Chapter 39 for more information about language handlers.
+(relation) The catalog pg_language registers languages in which you can write functions or stored procedures. See CREATE LANGUAGE and Chapter 40 for more information about language handlers.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 lanname: Name of the language
 lanowner: Owner of the language

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The view pg_locks provides access to information about the locks held by open transactions within the database server. See Chapter 13 for more discussion of locking. pg_locks contains one row per active lockable object, requested lock mode, and relevant transaction. Thus, the same lockable object might appear many times, if multiple transactions are holding or waiting for locks on it. However, an object that currently has no locks on it will not appear at all. There are several distinct types of lockable objects: whole relations (e.g., tables), individual pages of relations, individual tuples of relations, transaction IDs (both virtual and permanent IDs), and general database objects (identified by class OID and object OID, in the same way as in pg_description or pg_depend). Also, the right to extend a relation is represented as a separate lockable object, as is the right to update pg_database.datfrozenxid. Also, "advisory" locks can be taken on numbers that have user-defined meanings.
+(relation) The view pg_locks provides access to information about the locks held by active processes within the database server. See Chapter 13 for more discussion of locking. pg_locks contains one row per active lockable object, requested lock mode, and relevant process. Thus, the same lockable object might appear many times, if multiple processes are holding or waiting for locks on it. However, an object that currently has no locks on it will not appear at all. There are several distinct types of lockable objects: whole relations (e.g., tables), individual pages of relations, individual tuples of relations, transaction IDs (both virtual and permanent IDs), and general database objects (identified by class OID and object OID, in the same way as in pg_description or pg_depend). Also, the right to extend a relation is represented as a separate lockable object, as is the right to update pg_database.datfrozenxid. Also, "advisory" locks can be taken on numbers that have user-defined meanings.
 locktype: Type of the lockable object: relation, extend, frozenid, page, tuple, transactionid, virtualxid, object, userlock, or advisory
 database: OID of the database in which the lock target exists, or zero if the target is a shared object, or null if the target is a transaction ID
 relation: OID of the relation targeted by the lock, or null if the target is not a relation or part of a relation

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_opclass defines index access method operator classes. Each operator class defines semantics for index columns of a particular data type and a particular index access method. An operator class essentially specifies that a particular operator family is applicable to a particular indexable column data type. The set of operators from the family that are actually usable with the indexed column are whichever ones accept the column's data type as their left-hand input. Operator classes are described at length in Section 35.14.
+(relation) The catalog pg_opclass defines index access method operator classes. Each operator class defines semantics for index columns of a particular data type and a particular index access method. An operator class essentially specifies that a particular operator family is applicable to a particular indexable column data type. The set of operators from the family that are actually usable with the indexed column are whichever ones accept the column's data type as their left-hand input. Operator classes are described at length in Section 36.14.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 opcmethod: Index access method operator class is for
 opcname: Name of this operator class

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_operator stores information about operators. See CREATE OPERATOR and Section 35.12 for more information.
+(relation) The catalog pg_operator stores information about operators. See CREATE OPERATOR and Section 36.12 for more information.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 oprname: Name of the operator
 oprnamespace: The OID of the namespace that contains this operator

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_opfamily defines operator families. Each operator family is a collection of operators and associated support routines that implement the semantics specified for a particular index access method. Furthermore, the operators in a family are all "compatible", in a way that is specified by the access method. The operator family concept allows cross-data-type operators to be used with indexes and to be reasoned about using knowledge of access method semantics. Operator families are described at length in Section 35.14.
+(relation) The catalog pg_opfamily defines operator families. Each operator family is a collection of operators and associated support routines that implement the semantics specified for a particular index access method. Furthermore, the operators in a family are all "compatible", in a way that is specified by the access method. The operator family concept allows cross-data-type operators to be used with indexes and to be reasoned about using knowledge of access method semantics. Operator families are described at length in Section 36.14.
 oid: Row identifier (hidden attribute; must be explicitly selected)
 opfmethod: Index access method operator family is for
 opfname: Name of this operator family

--- 9.5
+++ 9.6
@@ -3,4 +3,4 @@
 statement: The query string submitted by the client to create this prepared statement. For prepared statements created via SQL, this is the PREPARE statement submitted by the client. For prepared statements created via the frontend/backend protocol, this is the text of the prepared statement itself.
 prepare_time: The time at which the prepared statement was created
 parameter_types: The expected parameter types for the prepared statement in the form of an array of regtype. The OID corresponding to an element of this array can be obtained by casting the regtype value to oid.
-from_sql: true if the prepared statement was created via the PREPARE SQL statement; false if the statement was prepared via the frontend/backend protocol
+from_sql: true if the prepared statement was created via the PREPARE SQL command; false if the statement was prepared via the frontend/backend protocol

9.5 → 9.6
+ proparallel  "char"

--- 9.5
+++ 9.6
@@ -1,3 +1,3 @@
-(relation) The pg_replication_origin catalog contains all replication origins created. For more on replication origins see Chapter 47.
+(relation) The pg_replication_origin catalog contains all replication origins created. For more on replication origins see Chapter 48.
 roident: A unique, cluster-wide identifier for the replication origin. Should never leave the system.
 roname: The external, user defined, name of a replication origin.

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The pg_replication_origin_status view contains information about how far replay for a certain origin has progressed. For more on replication origins see Chapter 47.
+(relation) The pg_replication_origin_status view contains information about how far replay for a certain origin has progressed. For more on replication origins see Chapter 48.
 local_id: internal node identifier
 external_id: external node identifier
 remote_lsn: The origin node's LSN up to which data has been replicated.

9.5 → 9.6
+ confirmed_flush_lsn  pg_lsn

--- 9.5
+++ 9.6
@@ -5,7 +5,7 @@
 rolcreaterole: Role can create more roles
 rolcreatedb: Role can create databases
 rolcanlogin: Role can log in. That is, this role can be given as the initial session authorization identifier
-rolreplication: Role is a replication role. That is, this role can initiate streaming replication (see Section 25.2.5) and set/unset the system backup mode using pg_start_backup and pg_stop_backup
+rolreplication: Role is a replication role. A replication role can initiate replication connections and create and drop replication slots.
 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

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_seclabel stores security labels on database objects. Security labels can be manipulated with the SECURITY LABEL command. For an easier way to view security labels, see Section 49.72. See also pg_shseclabel, which performs a similar function for security labels of database objects that are shared across a database cluster.
+(relation) The catalog pg_seclabel stores security labels on database objects. Security labels can be manipulated with the SECURITY LABEL command. For an easier way to view security labels, see Section 50.74. See also pg_shseclabel, which performs a similar function for security labels of database objects that are shared across a database cluster.
 objoid: The OID of the object this security label pertains to
 classoid: The OID of the system catalog this object appears in
 objsubid: For a security label on a table column, this is the column number (the objoid and classoid refer to the table itself). For all other object types, this column is zero.

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The catalog pg_shseclabel stores security labels on shared database objects. Security labels can be manipulated with the SECURITY LABEL command. For an easier way to view security labels, see Section 49.72. See also pg_seclabel, which performs a similar function for security labels involving objects within a single database. Unlike most system catalogs, pg_shseclabel is shared across all databases of a cluster: there is only one copy of pg_shseclabel per cluster, not one per database.
+(relation) The catalog pg_shseclabel stores security labels on shared database objects. Security labels can be manipulated with the SECURITY LABEL command. For an easier way to view security labels, see Section 50.74. See also pg_seclabel, which performs a similar function for security labels involving objects within a single database. Unlike most system catalogs, pg_shseclabel is shared across all databases of a cluster: there is only one copy of pg_shseclabel per cluster, not one per database.
 objoid: The OID of the object this security label pertains to
 classoid: The OID of the system catalog this object appears in
 provider: The label provider associated with this label.

9.5 → 9.6
+ wait_event_type  text
+ wait_event  text
- waiting  boolean

--- 9.5
+++ 9.6
@@ -0,0 +1,11 @@
+pid  integer
+datid  oid
+datname  name
+relid  oid
+phase  text
+heap_blks_total  bigint
+heap_blks_scanned  bigint
+heap_blks_vacuumed  bigint
+index_vacuum_count  bigint
+max_dead_tuples  bigint
+num_dead_tuples  bigint

--- 9.5
+++ 9.6
@@ -0,0 +1,12 @@
+pid  integer
+status  text
+receive_start_lsn  pg_lsn
+receive_start_tli  integer
+received_lsn  pg_lsn
+received_tli  integer
+last_msg_send_time  timestamp with time zone
+last_msg_receipt_time  timestamp with time zone
+latest_end_lsn  pg_lsn
+latest_end_time  timestamp with time zone
+slot_name  text
+conninfo  text

--- 9.5
+++ 9.6
@@ -1,4 +1,4 @@
-(relation) The view pg_timezone_names provides a list of time zone names that are recognized by SET TIMEZONE, along with their associated abbreviations, UTC offsets, and daylight-savings status. (Technically, PostgreSQL uses UT1 rather than UTC because leap seconds are not handled.) Unlike the abbreviations shown in pg_timezone_abbrevs, many of these names imply a set of daylight-savings transition date rules. Therefore, the associated information changes across local DST boundaries. The displayed information is computed based on the current value of CURRENT_TIMESTAMP.
+(relation) The view pg_timezone_names provides a list of time zone names that are recognized by SET TIMEZONE, along with their associated abbreviations, UTC offsets, and daylight-savings status. (Technically, PostgreSQL does not use UTC because leap seconds are not handled.) Unlike the abbreviations shown in pg_timezone_abbrevs, many of these names imply a set of daylight-savings transition date rules. Therefore, the associated information changes across local DST boundaries. The displayed information is computed based on the current value of CURRENT_TIMESTAMP.
 name: Time zone name
 abbrev: Time zone abbreviation
 utc_offset: Offset from UTC (positive means east of Greenwich)

--- 9.5
+++ 9.6
@@ -6,7 +6,7 @@
 typlen: For a fixed-size type, typlen is the number of bytes in the internal representation of the type. But for a variable-length type, typlen is negative. -1 indicates a "varlena" type (one that has a length word), -2 indicates a null-terminated C string.
 typbyval: typbyval determines whether internal routines pass a value of this type by value or by reference. typbyval had better be false if typlen is not 1, 2, or 4 (or 8 on machines where Datum is 8 bytes). Variable-length types are always passed by reference. Note that typbyval can be false even if the length would allow pass-by-value.
 typtype: typtype is b for a base type, c for a composite type (e.g., a table's row type), d for a domain, e for an enum type, p for a pseudo-type, or r for a range type. See also typrelid and typbasetype.
-typcategory: typcategory is an arbitrary classification of data types that is used by the parser to determine which implicit casts should be "preferred". See Table 49-55.
+typcategory: typcategory is an arbitrary classification of data types that is used by the parser to determine which implicit casts should be "preferred". See Table 50-56.
 typispreferred: True if the type is a preferred cast target within its typcategory
 typisdefined: True if the type is defined, false if this is a placeholder entry for a not-yet-defined type. When typisdefined is false, nothing except the type name, namespace, and OID can be relied on.
 typdelim: Character that separates two values of this type when parsing array input. Note that the delimiter is associated with the array element data type, not the array data type.