table: docs: fix typos and grammar.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20190404055138[email protected]

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 0e38382f319e0c63a7e510e9d656f0ca7cab2f6e..17018637f1720b7ccdcb3f2bed3116c26e173e33 100644 (file)
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -587,7 +587,7 @@
    The catalog pg_am stores information about
    relation access methods.  There is one row for each access method supported
    by the system.
-   Currently, only table and indexes have access methods. The requirements for table
+   Currently, only tables and indexes have access methods. The requirements for table
    and index access methods are discussed in detail in  and
     respectively.
   

diff --git a/doc/src/sgml/ref/select_into.sgml b/doc/src/sgml/ref/select_into.sgml
index 17bed24743dc5cbed1e332504572f1dc7629fb0f..b1af52a4da127048f0043bd70251f6a610bee1f5 100644 (file)
--- a/doc/src/sgml/ref/select_into.sgml
+++ b/doc/src/sgml/ref/select_into.sgml
@@ -106,11 +106,11 @@ SELECT [ ALL | DISTINCT [ ON ( expression
   
 
   
-   In contrast to CREATE TABLE AS SELECT
+   In contrast to CREATE TABLE AS, SELECT
    INTO does not allow to specify properties like a table's access
    method with  or the table's
    tablespace with . Use 
-   linkend="sql-createtableas"/> if necessary.  Therefore the default table
+   linkend="sql-createtableas"/> if necessary.  Therefore, the default table
    access method is chosen for the new table. See 
    linkend="guc-default-table-access-method"/> for more information.
   


diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml

index 62333e31a0221d8cea50fb75741f8ea0d6008f55..e0915b6fa01f07ce6dab71263876245abcbdae1f 100644 (file)

--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -189,11 +189,11 @@ there.
 
 
 
- Note that the following sections describe the way the builtin
+ Note that the following sections describe the behavior of the builtin
  heap table access method,
- and the builtin index access methods work. Due
- to the extensible nature of PostgreSQL other types
- of access method might work similar or not.
+ and the builtin index access methods. Due
+ to the extensible nature of PostgreSQL, other
+ access methods might work differently.
 
 
 
@@ -703,11 +703,11 @@ erased (they will be recreated automatically as needed).
 This section provides an overview of the page format used within
 PostgreSQL tables and indexes.
   
-    Actually, neither table nor index access methods need not use this page
-    format.  All the existing index methods do use this basic format, but the
-    data kept on index metapages usually doesn't follow the item layout
-    rules. The heap table access method also always uses
-    this format.
+    Actually, use of this page format is not required for either table or
+    index access methods. The heap table access method
+    always uses this format.  All the existing index methods also use the
+    basic format, but the data kept on index metapages usually doesn't follow
+    the item layout rules.
   
 
 Sequences and TOAST tables are formatted just like a regular table.


diff --git a/doc/src/sgml/tableam.sgml b/doc/src/sgml/tableam.sgml

index 8d9bfd813078906cfe65805df651d9872c2becf2..6c9f820acae02e4670273d7301b8fce34b3a0410 100644 (file)

--- a/doc/src/sgml/tableam.sgml
+++ b/doc/src/sgml/tableam.sgml
@@ -48,33 +48,33 @@
   callbacks and their behavior is defined in the
   TableAmRoutine structure (with comments inside the
   struct defining the requirements for callbacks). Most callbacks have
-  wrapper functions, which are documented for the point of view of a user,
-  rather than an implementor, of the table access method.  For details,
+  wrapper functions, which are documented from the point of view of a user
+  (rather than an implementor) of the table access method.  For details,
   please refer to the 
   src/include/access/tableam.h file.
  
 
  
-  To implement a access method, an implementor will typically need to
-  implement a AM specific type of tuple table slot (see
+  To implement an access method, an implementor will typically need to
+  implement an AM-specific type of tuple table slot (see
   
-   src/include/executor/tuptable.h) which allows
+   src/include/executor/tuptable.h), which allows
    code outside the access method to hold references to tuples of the AM, and
    to access the columns of the tuple.
  
 
  
-  Currently the the way an AM actually stores data is fairly
-  unconstrained. It is e.g. possible to use postgres' shared buffer cache,
-  but not required. In case shared buffers are used, it likely makes to
-  postgres' standard page layout described in 
-  linkend="storage-page-layout"/>.
+  Currently, the way an AM actually stores data is fairly unconstrained. For
+  example, it's possible, but not required, to use postgres' shared buffer
+  cache.  In case it is used, it likely makes sense to use
+  PostgreSQL's standard page layout as described in
+  linkend="storage-page-layout"/>.
  
 
  
   One fairly large constraint of the table access method API is that,
   currently, if the AM wants to support modifications and/or indexes, it is
-  necessary that each tuple has a tuple identifier (TID)
+  necessary for each tuple to have a tuple identifier (TID)
   consisting of a block number and an item number (see also 
   linkend="storage-page-layout"/>).  It is not strictly necessary that the
   sub-parts of TIDs have the same meaning they e.g. have
@@ -83,13 +83,14 @@
  
 
  
-  For crash safety an AM can use postgres' 
-  linkend="wal">WAL, or a custom approach can be
-  implemented.  If WAL is chosen, either 
-  linkend="generic-wal">Generic WAL Records can be used — which
-  implies higher WAL volume but is easy, or a new type of
-  WAL records can be implemented — but that
-  currently requires modifications of core code (namely modifying
+  For crash safety, an AM can use postgres' 
+  linkend="wal">WAL, or a custom implementation.
+  If WAL is chosen, either 
+  linkend="generic-wal">Generic WAL Records can be used,
+  or a new type of WAL records can be implemented.
+  Generic WAL Records are easy, but imply higher WAL volume.
+  Implementation of a new type of WAL record
+  currently requires modifications to core code (specifically,
   src/include/access/rmgrlist.h).
  
 
@@ -103,8 +104,8 @@
  
   Any developer of a new table access method can refer to
   the existing heap implementation present in
-  src/backend/heap/heapam_handler.c for more details of
-  how it is implemented.
+  src/backend/heap/heapam_handler.c for details of
+  its implementation.
  
 
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};

diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index 62333e31a0221d8cea50fb75741f8ea0d6008f55..e0915b6fa01f07ce6dab71263876245abcbdae1f 100644 (file)
--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -189,11 +189,11 @@ there.
 
 
 
- Note that the following sections describe the way the builtin
+ Note that the following sections describe the behavior of the builtin
  heap table access method,
- and the builtin index access methods work. Due
- to the extensible nature of PostgreSQL other types
- of access method might work similar or not.
+ and the builtin index access methods. Due
+ to the extensible nature of PostgreSQL, other
+ access methods might work differently.
 
 
 
@@ -703,11 +703,11 @@ erased (they will be recreated automatically as needed).
 This section provides an overview of the page format used within
 PostgreSQL tables and indexes.
   
-    Actually, neither table nor index access methods need not use this page
-    format.  All the existing index methods do use this basic format, but the
-    data kept on index metapages usually doesn't follow the item layout
-    rules. The heap table access method also always uses
-    this format.
+    Actually, use of this page format is not required for either table or
+    index access methods. The heap table access method
+    always uses this format.  All the existing index methods also use the
+    basic format, but the data kept on index metapages usually doesn't follow
+    the item layout rules.
   
 
 Sequences and TOAST tables are formatted just like a regular table.

diff --git a/doc/src/sgml/tableam.sgml b/doc/src/sgml/tableam.sgml
index 8d9bfd813078906cfe65805df651d9872c2becf2..6c9f820acae02e4670273d7301b8fce34b3a0410 100644 (file)
--- a/doc/src/sgml/tableam.sgml
+++ b/doc/src/sgml/tableam.sgml
@@ -48,33 +48,33 @@
   callbacks and their behavior is defined in the
   TableAmRoutine structure (with comments inside the
   struct defining the requirements for callbacks). Most callbacks have
-  wrapper functions, which are documented for the point of view of a user,
-  rather than an implementor, of the table access method.  For details,
+  wrapper functions, which are documented from the point of view of a user
+  (rather than an implementor) of the table access method.  For details,
   please refer to the 
   src/include/access/tableam.h file.
  
 
  
-  To implement a access method, an implementor will typically need to
-  implement a AM specific type of tuple table slot (see
+  To implement an access method, an implementor will typically need to
+  implement an AM-specific type of tuple table slot (see
   
-   src/include/executor/tuptable.h) which allows
+   src/include/executor/tuptable.h), which allows
    code outside the access method to hold references to tuples of the AM, and
    to access the columns of the tuple.
  
 
  
-  Currently the the way an AM actually stores data is fairly
-  unconstrained. It is e.g. possible to use postgres' shared buffer cache,
-  but not required. In case shared buffers are used, it likely makes to
-  postgres' standard page layout described in 
-  linkend="storage-page-layout"/>.
+  Currently, the way an AM actually stores data is fairly unconstrained. For
+  example, it's possible, but not required, to use postgres' shared buffer
+  cache.  In case it is used, it likely makes sense to use
+  PostgreSQL's standard page layout as described in
+  linkend="storage-page-layout"/>.
  
 
  
   One fairly large constraint of the table access method API is that,
   currently, if the AM wants to support modifications and/or indexes, it is
-  necessary that each tuple has a tuple identifier (TID)
+  necessary for each tuple to have a tuple identifier (TID)
   consisting of a block number and an item number (see also 
   linkend="storage-page-layout"/>).  It is not strictly necessary that the
   sub-parts of TIDs have the same meaning they e.g. have
@@ -83,13 +83,14 @@
  
 
  
-  For crash safety an AM can use postgres' 
-  linkend="wal">WAL, or a custom approach can be
-  implemented.  If WAL is chosen, either 
-  linkend="generic-wal">Generic WAL Records can be used — which
-  implies higher WAL volume but is easy, or a new type of
-  WAL records can be implemented — but that
-  currently requires modifications of core code (namely modifying
+  For crash safety, an AM can use postgres' 
+  linkend="wal">WAL, or a custom implementation.
+  If WAL is chosen, either 
+  linkend="generic-wal">Generic WAL Records can be used,
+  or a new type of WAL records can be implemented.
+  Generic WAL Records are easy, but imply higher WAL volume.
+  Implementation of a new type of WAL record
+  currently requires modifications to core code (specifically,
   src/include/access/rmgrlist.h).
  
 
@@ -103,8 +104,8 @@
  
   Any developer of a new table access method can refer to
   the existing heap implementation present in
-  src/backend/heap/heapam_handler.c for more details of
-  how it is implemented.
+  src/backend/heap/heapam_handler.c for details of
+  its implementation.
  
 
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};