Doc: various fixups

* Use  tags for CONNECTION_* #defines

We were using an inconsistent mix of  and sometimes 
tags.

* Use  tag for libpq

There was a mix of  and 

Also fix a whitespace issue.

None of these seem critical enough mistakes to backpatch.

Author: Noboru Saito 
Discussion: https://postgr.es/m/CAAM3qnJtv5YbjpwDfVOYN2gZ9zGSLFM1UGJgptSXmwfifOZJFQ@mail.gmail.com

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 3be66789ba7b5b2b608f4d4200eb90ce79a8b64c..8cdd2997d43c3640f1e590c1a4319c09b7ec0436 100644 (file)
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -378,7 +378,7 @@ PostgresPollingStatusType PQconnectPoll(PGconn *conn);
       
        At any time during connection, the status of the connection can be
        checked by calling . If this call returns CONNECTION_BAD, then the
-       connection procedure has failed; if the call returns <function>CONNECTION_OK>, then the
+       connection procedure has failed; if the call returns <symbol>CONNECTION_OK>, then the
        connection is ready.  Both of these states are equally detectable
        from the return value of PQconnectPoll, described above. Other states might also occur
        during (and only during) an asynchronous connection procedure. These
@@ -1922,7 +1922,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
       sslkeylogfile
       
        
-        This parameter specifies the location where <literal>libpq>
+        This parameter specifies the location where <application>libpq>
         will log keys used in this SSL context.  This is useful for debugging
         PostgreSQL protocol interactions or client
         connections using network inspection tools like
@@ -1956,7 +1956,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
         Enter PEM pass phrase:
         prompt that OpenSSL will emit by default
         when an encrypted client certificate key is provided to
-        <literal>libpq>.
+        <application>libpq>.
        
        
         If the key is not encrypted this parameter is ignored. The parameter
@@ -2811,14 +2811,14 @@ ConnStatusType PQstatus(const PGconn *conn);
       
        The status can be one of a number of values.  However, only two of
        these are seen outside of an asynchronous connection procedure:
-       <literal>CONNECTION_OKl> and
-       <literal>CONNECTION_BADl>. A good connection to the database
-       has the status <literal>CONNECTION_OKl>.  A failed
+       <symbol>CONNECTION_OKl> and
+       <symbol>CONNECTION_BADl>. A good connection to the database
+       has the status <symbol>CONNECTION_OKl>.  A failed
        connection attempt is signaled by status
-       <literal>CONNECTION_BADl>.  Ordinarily, an OK status will
+       <symbol>CONNECTION_BADl>.  Ordinarily, an OK status will
        remain so until , but a communications
        failure might result in the status changing to
-       <literal>CONNECTION_BADl> prematurely.  In that case the
+       <symbol>CONNECTION_BADl> prematurely.  In that case the
        application could try to recover by calling
        .
       
@@ -6628,7 +6628,7 @@ PostgresPollingStatusType PQcancelPoll(PGcancelConn *cancelConn);
        checked by calling .
        If this call returns CONNECTION_BAD, then
        the cancel procedure has failed; if the call returns
-       <function>CONNECTION_OK>, then cancel request was
+       <symbol>CONNECTION_OK>, then cancel request was
        successfully dispatched.
        Both of these states are equally detectable from the return value of
        PQcancelPoll, described above.
@@ -6750,15 +6750,15 @@ ConnStatusType PQcancelStatus(const PGcancelConn *cancelConn);
       
        The status can be one of a number of values.  However, only three of
        these are seen outside of an asynchronous cancel procedure:
-       <literal>CONNECTION_ALLOCATEDl>,
-       <literal>CONNECTION_OKl> and
-       <literal>CONNECTION_BADl>. The initial state of a
+       <symbol>CONNECTION_ALLOCATEDl>,
+       <symbol>CONNECTION_OKl> and
+       <symbol>CONNECTION_BADl>. The initial state of a
        PGcancelConn that's successfully created using
-        is <literal>CONNECTION_ALLOCATEDl>.
+        is <symbol>CONNECTION_ALLOCATEDl>.
        A cancel request that was successfully dispatched
-       has the status <literal>CONNECTION_OKl>.  A failed
+       has the status <symbol>CONNECTION_OKl>.  A failed
        cancel attempt is signaled by status
-       <literal>CONNECTION_BADl>.  An OK status will
+       <symbol>CONNECTION_BADl>.  An OK status will
        remain so until  or
         is called.
       
@@ -8283,7 +8283,7 @@ size_t PQresultMemorySize(const PGresult *res);
 
     
      
-      Return the version of <productname>libpq> that is being used.
+      Return the version of <application>libpq> that is being used.
 
 int PQlibVersion(void);
 
@@ -8534,7 +8534,7 @@ typedef struct
        evtInfo pointer should be cast to a
        PGEventRegister *.  This structure contains a
        PGconn that should be in the
-       <literal>CONNECTION_OKl> status; guaranteed if one calls
+       <symbol>CONNECTION_OKl> status; guaranteed if one calls
         right after obtaining a good
        PGconn.  When returning a failure code, all
        cleanup must be performed as no PGEVT_CONNDESTROY

diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 1c4ae38f1b99299d4696c3f4df85a67cca5a69c5..3f2bcd45a1ea79c21a8f500238fc42b7f7522431 100644 (file)
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -898,7 +898,6 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx,
       callback might also error out due to simultaneous rollback of
       this very same transaction. In that case, the logical decoding of this
       aborted transaction is stopped gracefully.
-
       The prefix is arbitrary null-terminated prefix
       which can be used for identifying interesting messages for the current
       plugin. And finally the message parameter holds