docs: cleanup in types/enums docs

diff --git a/docs/api/types.rst b/docs/api/types.rst
index c333ee00b39a42ff11b1e7352e28f13a1531e814..01f970e1aa86473d446db5f1d901c62b607821be 100644 (file)
--- a/docs/api/types.rst
+++ b/docs/api/types.rst
@@ -83,8 +83,8 @@ as a subtype.
         :return: a `!TypeInfo` object (or subclass) populated with the type
             information, `!None` if not found.
 
-        If the connection is async the function will behave as a coroutine and
-        the caller will need to `await` on it to get the result::
+        If the connection is async, `!fetch()` will behave as a coroutine and
+        the caller will need to `!await` on it to get the result::
 
             t = await TypeInfo.fetch(aconn, "mytype")
 
@@ -101,10 +101,11 @@ as a subtype.
         database as a list of the base type.
 
 
-For recursive types, Psycopg offers a few `!TypeInfo` subclasses which can be
-used to extract more complete information, such as
-`~psycopg.types.composite.CompositeInfo`, `~psycopg.types.range.RangeInfo`,
-`~psycopg.types.multirange.MultirangeInfo`.
+In order to get information about dynamic PostgreSQL types, Psycopg offers a
+few `!TypeInfo` subclasses, whose `!fetch()` method can extract more complete
+information about the type, such as `~psycopg.types.composite.CompositeInfo`,
+`~psycopg.types.range.RangeInfo`, `~psycopg.types.multirange.MultirangeInfo`,
+`~psycopg.types.enum.EnumInfo`.
 
 `!TypeInfo` objects are collected in `TypesRegistry` instances, which help type
 information lookup. Every `~psycopg.adapt.AdaptersMap` exposes its type map on

diff --git a/docs/basic/adapt.rst b/docs/basic/adapt.rst
index 8871eb29fcd0733c6244e6af5a216da015679719..4b00329875ff7983043dfbc1d0b7049072461466 100644 (file)
--- a/docs/basic/adapt.rst
+++ b/docs/basic/adapt.rst
@@ -397,20 +397,25 @@ and registered enums is different.
     names as value. The unknown oid is used, so PostgreSQL should be able to
     use this string in most contexts (such as an enum or a text field).
 
+    .. versionchanged:: 3.1
+        In previous version dumping pure enums is not supported and raise a
+        "cannot adapt" error.
+
   - Mix-in enums are dumped according to their mix-in type (because a `class
     MyIntEnum(int, Enum)` is more specifically an `!int` than an `!Enum`, so
     it's dumped by default according to `!int` rules).
 
   - PostgreSQL enums are loaded as Python strings. If you want to load arrays
-    of such enums you will have to find their ids using
-    `types.TypeInfo.fetch()` and `~types.TypeInfo.register()`.
+    of such enums you will have to find their OIDs using `types.TypeInfo.fetch()`
+    and register them using `~types.TypeInfo.register()`.
 
 - If the enum is registered (using `~types.enum.EnumInfo`\ `!.fetch()` and
   `~types.enum.register_enum()`):
 
   - Enums classes, both pure and mixed-in, are dumped by name.
 
-  - The registered PostgreSQL enum is loaded back as the registered Python enum members.
+  - The registered PostgreSQL enum is loaded back as the registered Python
+    enum members.
 
 .. autoclass:: psycopg.types.enum.EnumInfo