diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index b6cf9adcb2..9f9f697fd8 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -169,32 +169,61 @@ 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
+ PostgreSQL supports two types of temporary tables,
+ Global Temporary table, and Local Temporary table.
+ Optionally, GLOBAL or LOCAL
+ can be written before TEMPORARY or TEMP.
+ The default type is the Local Temporary table.
+
+
+
+
+ Global Temporary Table
+
+
+ The Global Temporary Table are defined just once and automatically exist
+ (starting with empty contents) in every session that needs them.
+ This means that the definition of a temporary table is persistent
+ and shared between sessions. When a temporary table is created
+ and writes some data, another newly created session also sees this table,
+ and found this table is empty.
+
+
+
+
+
+ Local Temporary Table
+
+
+ The Local Temporary Table are automatically dropped at the end of a
+ session, 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 data stored in a temporary table can be cleaned up at the
+ end of the current transaction. (see ON COMMIT below).
+
+
+ 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.
-
@@ -2125,13 +2154,15 @@ 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
+ same as that of the SQL standard, Local Temporary Table does not.
+
+
+
+ First, in the standard, temporary tables are defined just once and
+ automatically exist (starting with empty contents) in every session
+ that needs them. The Local Temporary Table 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
@@ -2139,37 +2170,22 @@ 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
- tables, where a local temporary table has a separate set of contents for
+ Second, 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
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.
+ has some differences with the SQL standard.
If the ON COMMIT clause is omitted, SQL specifies that the
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.