More tag cleanups.

diff --git a/doc/src/sgml/jdbc.sgml b/doc/src/sgml/jdbc.sgml
index dc9b3847c2e932581bbfaa12b6d3b3f4d1c0c82a..fc3106ad3ebd5d7f3712d028def474aff493bba6 100644 (file)
--- a/doc/src/sgml/jdbc.sgml
+++ b/doc/src/sgml/jdbc.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -584,7 +584,7 @@ st.close();
     need to understand the limitations of each method.  The 
     bytea datatype is not well suited for storing very 
     large amounts of binary data.  While a column of type 
-    byteabytea> can hold upto 1Gig of binary data, it would 
+    byteatype> can hold upto 1Gig of binary data, it would 
     require a huge amount of memory (RAM) to 
     process such a large value.  The Large Object method for 
     storing binary data is better suited to storing very large values, 
@@ -623,7 +623,7 @@ st.close();
   
     To use the Large Object functionality you can use either the 
     LargeObject API
-    provided by the PostgreSQLiton> 
+    provided by the PostgreSQLtion> 
     JDBC Driver, or by using the 
     getBLOB() and setBLOB()
     methods.
@@ -644,7 +644,7 @@ st.close();
       and setBLOB() methods may no longer 
       interact with Large Objects and will instead work on 
       bytea datatypes.  So it is recommended that you 
-      use the LargeObject n>API 
+      use the LargeObject m>API 
       if you intend to use Large Objects.
   
 
@@ -2492,7 +2492,7 @@ public void unlink(int oid) throws SQLException
   
 
   
-   The PostgreSQL n>JDBC Driver
+   The PostgreSQL m>JDBC Driver
    is thread safe.
    Consequently, if your application uses multiple threads then you do
    not have to worry about complex algorithms to ensure that only one