Fix alphabetization in catalogs.sgml.
authorTom Lane
Mon, 30 Dec 2013 18:27:51 +0000 (13:27 -0500)
committerTom Lane
Mon, 30 Dec 2013 18:27:51 +0000 (13:27 -0500)
Some recent patches seem not to have grasped the concept that the catalogs
are described in alphabetical order.

doc/src/sgml/catalogs.sgml

index 558b41b9bc57040d7e9fe889c8281b7f6a1a1dfd..2230c9392c0a79386ab71ee43b160209b8670ec7 100644 (file)
      
 
      
-      nstraint">pg_constraint
-      check constraints, unique constraints, primary key constraints, foreign key constraints
+      llation">pg_collation
+      collations (locale information)
      
 
      
-      llation">pg_collation
-      collations (locale information)
+      nstraint">pg_constraint
+      check constraints, unique constraints, primary key constraints, foreign key constraints
      
 
      
   
  
 
event-trigger">
-  <structname>pg_<span class="marked">event_trigger</span></structname>
collation">
+  <structname>pg_<span class="marked">collation</span></structname>
 
-  event-trigger">
-   pg_event_trigger
+  collation">
+   pg_collation
   
 
   
-   The catalog pg_event_trigger stores event triggers.
-   See  for more information.
+   The catalog pg_collation describes the
+   available collations, which are essentially mappings from an SQL
+   name to operating system locale categories.
+   See  for more information.
   
 
   
-   <structname>pg_<span class="marked">event_trigger</span></> Columns
+   <structname>pg_<span class="marked">collation</span></> Columns
 
    
     
 
     
      
-      evtname
-      name
+      oid
+      oid
       
-      Trigger name (must be unique)
+      Row identifier (hidden attribute; must be explicitly selected)
      
 
      
-      evtevent
+      collname
       name
       
-      Identifies the event for which this trigger fires
+      Collation name (unique per namespace and encoding)
      
 
      
-      evtowner
+      collnamespace
       oid
-      pg_authid.oid
-      Owner of the event trigger
+      pg_namespace.oid
+      
+       The OID of the namespace that contains this collation
+      
      
 
      
-      evtfoid
+      collowner
       oid
-      proc">pg_proc.oid
-      The function to be called
+      authid">pg_authid.oid
+      Owner of the collation
      
 
      
-      evtenabled
-      char
+      collencoding
+      int4
       
-      
-       Controls in which  modes
-       the event trigger fires.
-       O = trigger fires in origin and local modes,
-       D = trigger is disabled,
-       R = trigger fires in replica mode,
-       A = trigger fires always.
-      
+      Encoding in which the collation is applicable, or -1 if it
+       works for any encoding
      
 
      
-      evttags
-      text[]
+      collcollate
+      name
       
-      
-        Command tags for which this trigger will fire.  If NULL, the firing
-        of this trigger is not restricted on the basis of the command tag.
-      
+      LC_COLLATE for this collation object
+     
+
+     
+      collctype
+      name
+      
+      LC_CTYPE for this collation object
      
     
    
   
+
+  
+   Note that the unique key on this catalog is (collname,
+   collencoding, collnamespace) not just
+   (collname, collnamespace).
+   PostgreSQL generally ignores all
+   collations that do not have collencoding equal to
+   either the current database's encoding or -1, and creation of new entries
+   with the same name as an entry with collencoding = -1
+   is forbidden.  Therefore it is sufficient to use a qualified SQL name
+   (schema.name) to identify a collation,
+   even though this is not unique according to the catalog definition.
+   The reason for defining the catalog this way is that
+   initdb fills it in at cluster initialization time with
+   entries for all locales available on the system, so it must be able to
+   hold entries for all encodings that might ever be used in the cluster.
+  
+
+  
+   In the template0 database, it could be useful to create
+   collations whose encoding does not match the database encoding,
+   since they could match the encodings of databases later cloned from
+   template0.  This would currently have to be done manually.
+  
  
 
  
     relation.
    
   
-
  
 
-  <structname>pg_collation</structname>
-
-  
-   pg_collation
-  
-
-  
-   The catalog pg_collation describes the
-   available collations, which are essentially mappings from an SQL
-   name to operating system locale categories.
-   See  for more information.
-  
-
-  
-   <structname>pg_collation</> Columns
-
-   
-    
-     
-      Name
-      Type
-      References
-      Description
-     
-    
-
-    
-     
-      oid
-      oid
-      
-      Row identifier (hidden attribute; must be explicitly selected)
-     
-
-     
-      collname
-      name
-      
-      Collation name (unique per namespace and encoding)
-     
-
-     
-      collnamespace
-      oid
-      pg_namespace.oid
-      
-       The OID of the namespace that contains this collation
-      
-     
-
-     
-      collowner
-      oid
-      pg_authid.oid
-      Owner of the collation
-     
-
-     
-      collencoding
-      int4
-      
-      Encoding in which the collation is applicable, or -1 if it
-       works for any encoding
-     
-
-     
-      collcollate
-      name
-      
-      LC_COLLATE for this collation object
-     
-
-     
-      collctype
-      name
-      
-      LC_CTYPE for this collation object
-     
-    
-   
-  
-
-  
-   Note that the unique key on this catalog is (collname,
-   collencoding, collnamespace) not just
-   (collname, collnamespace).
-   PostgreSQL generally ignores all
-   collations that do not have collencoding equal to
-   either the current database's encoding or -1, and creation of new entries
-   with the same name as an entry with collencoding = -1
-   is forbidden.  Therefore it is sufficient to use a qualified SQL name
-   (schema.name) to identify a collation,
-   even though this is not unique according to the catalog definition.
-   The reason for defining the catalog this way is that
-   initdb fills it in at cluster initialization time with
-   entries for all locales available on the system, so it must be able to
-   hold entries for all encodings that might ever be used in the cluster.
-  
-
-  
-   In the template0 database, it could be useful to create
-   collations whose encoding does not match the database encoding,
-   since they could match the encodings of databases later cloned from
-   template0.  This would currently have to be done manually.
-  
 
  
   <structname>pg_conversion</structname>
  
 
 
+  <structname>pg_event_trigger</structname>
+
+  
+   pg_event_trigger
+  
+
+  
+   The catalog pg_event_trigger stores event triggers.
+   See  for more information.
+  
+
+  
+   <structname>pg_event_trigger</> Columns
+
+   
+    
+     
+      Name
+      Type
+      References
+      Description
+     
+    
+
+    
+     
+      evtname
+      name
+      
+      Trigger name (must be unique)
+     
+
+     
+      evtevent
+      name
+      
+      Identifies the event for which this trigger fires
+     
+
+     
+      evtowner
+      oid
+      pg_authid.oid
+      Owner of the event trigger
+     
+
+     
+      evtfoid
+      oid
+      pg_proc.oid
+      The function to be called
+     
+
+     
+      evtenabled
+      char
+      
+      
+       Controls in which  modes
+       the event trigger fires.
+       O = trigger fires in origin and local modes,
+       D = trigger is disabled,
+       R = trigger fires in replica mode,
+       A = trigger fires always.
+      
+     
+
+     
+      evttags
+      text[]
+      
+      
+        Command tags for which this trigger will fire.  If NULL, the firing
+        of this trigger is not restricted on the basis of the command tag.
+      
+     
+    
+   
+  
+
+
  
   <structname>pg_extension</structname>