Fix a couple of stray misuses of "binary compatible".

diff --git a/doc/src/sgml/ref/create_cast.sgml b/doc/src/sgml/ref/create_cast.sgml
index 2ef9a7978989748e15aa1a7a635d9b7d77540a30..ea56f66857b35186cc8f10a054fb74eee082d42f 100644 (file)
--- a/doc/src/sgml/ref/create_cast.sgml
+++ b/doc/src/sgml/ref/create_cast.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  
@@ -294,7 +294,7 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
    the same name as a data type, returned that data type, and took one
    argument of a different type was automatically a cast function.
    This convention has been abandoned in face of the introduction of
-   schemas and to be able to represent binary compatible casts in the
+   schemas and to be able to represent binary-coercible casts in the
    system catalogs.  The built-in cast functions still follow this naming
    scheme, but they have to be shown as casts in the system catalog
    pg_cast as well.
@@ -324,7 +324,7 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
     exactly match any existing function, but name is the name
     of a data type and pg_cast provides a binary-coercible cast
     to this type from the type of x, then the call will be
-    construed as a binary-compatible cast.  This exception is made so that
+    construed as a binary-coercible cast.  This exception is made so that
     binary-coercible casts can be invoked using functional syntax, even
     though they lack any function.  Likewise, if there is no
     pg_cast entry but the cast would be to or from a string