diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 473a0a4aeb..e510bde8ac 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -169,32 +169,67 @@ WITH ( MODULUS numeric_literal, REM
If specified, the table is created as a temporary table.
- Temporary tables are automatically dropped at the end of a
- session, or optionally at the end of the current transaction
- (see ON COMMIT below). The default
- search_path includes the temporary schema first and so identically
- named existing permanent tables are not chosen for new plans
+ Optionally, GLOBAL or LOCAL
+ can be written before TEMPORARY or TEMP.
+ They represent two types of temporary tables supported by PostgreSQL:
+ global temporary table and local temporary table. Without specified
+ GLOBAL or LOCAL, a local temporary table is created by default.
+
+
+
+ Both types of temporary tables’ data are truncated at the
+ end of a session or optionally at the end of the current transaction.
+ (see ON COMMIT below). For global temporary table,
+ its schema is reserved and reused by future sessions or transactions.
+ For local temporary table, both its data and its schema are dropped.
+
+
+
+
+ Global Temporary Table
+
+
+ Global temporary table are defined just once and automatically exist
+ (starting with empty contents) in every session that needs them.
+ The schema definition of temporary tables is persistent and shared among sessions.
+ However, the data in temporary tables are kept private to sessions themselves,
+ even though they use same name and same schema.
+
+
+
+
+
+ Local Temporary Table
+
+
+ Local temporary table are automatically dropped at the end of a
+ session (include schema and data). Future sessions need to create
+ their own temporary tables when they are used.
+
+
+ The default search_path includes the temporary schema first and so
+ identically named existing permanent tables are not chosen for new plans
while the temporary table exists, unless they are referenced
with schema-qualified names. Any indexes created on a temporary
table are automatically temporary as well.
+
+
+
-
- The autovacuum daemon cannot
- access and therefore cannot vacuum or analyze temporary tables.
- For this reason, appropriate vacuum and analyze operations should be
- performed via session SQL commands. For example, if a temporary
- table is going to be used in complex queries, it is wise to run
- ANALYZE on the temporary table after it is populated.
-
+
+ The autovacuum daemon cannot
+ access and therefore cannot vacuum or analyze temporary tables.
+ For this reason, appropriate vacuum and analyze operations should be
+ performed via session SQL commands. For example, if a temporary
+ table is going to be used in complex queries, it is wise to run
+ ANALYZE on the temporary table after it is populated.
+
+
+ The Temporary table resembles the SQL standard, but has some differences.
+ see below.
+
-
- Optionally, GLOBAL or LOCAL
- can be written before TEMPORARY or TEMP.
- This presently makes no difference in PostgreSQL
- and is deprecated; see
- below.
-
@@ -2133,13 +2168,17 @@ CREATE TABLE cities_partdef
Temporary Tables
- Although the syntax of CREATE TEMPORARY TABLE
- resembles that of the SQL standard, the effect is not the same. In the
- standard,
- temporary tables are defined just once and automatically exist (starting
- with empty contents) in every session that needs them.
- PostgreSQL instead
- requires each session to issue its own CREATE TEMPORARY
+ Although the syntax of CREATE GLOBAL/LOCAL TEMPORARY TABLE
+ resembles that of the SQL standard, the effect is not the same.
+ The global temporary table follows the SQL standards while local temporary
+ table does not.
+
+
+
+ First, in the standard, both global and local temporary tables are defined just
+ once and automatically exist (starting with empty contents) in every session
+ that needs them. For local temporary tables, PostgreSQL
+ instead requires each session to issue its own CREATE LOCAL TEMPORARY
TABLE command for each temporary table to be used. This allows
different sessions to use the same temporary table name for different
purposes, whereas the standard's approach constrains all instances of a
@@ -2147,29 +2186,14 @@ CREATE TABLE cities_partdef
- The standard's definition of the behavior of temporary tables is
- widely ignored. PostgreSQL's behavior
- on this point is similar to that of several other SQL databases.
-
-
-
- The SQL standard also distinguishes between global and local temporary
+ Second, the SQL standard distinguishes between global and local temporary
tables, where a local temporary table has a separate set of contents for
each SQL module within each session, though its definition is still shared
- across sessions. Since PostgreSQL does not
+ across sessions. Since PostgreSQL does not
support SQL modules, this distinction is not relevant in
PostgreSQL.
-
- For compatibility's sake, PostgreSQL will
- accept the GLOBAL and LOCAL keywords
- in a temporary table declaration, but they currently have no effect.
- Use of these keywords is discouraged, since future versions of
- PostgreSQL might adopt a more
- standard-compliant interpretation of their meaning.
-
-
The ON COMMIT clause for temporary tables
also resembles the SQL standard, but has some differences.
@@ -2177,7 +2201,8 @@ CREATE TABLE cities_partdef
default behavior is ON COMMIT DELETE ROWS. However, the
default behavior in PostgreSQL is
ON COMMIT PRESERVE ROWS. The ON COMMIT
- DROP option does not exist in SQL.
+ DROP option does not exist in SQL and is not supported by
+ global temporary table.
--
2.30.1 (Apple Git-130)