Run search and replace of symbolic module names

Replaces a wide array of Sphinx-relative doc references
with an abbreviated absolute form now supported by
zzzeeksphinx.

Change-Id: I94bffcc3f37885ffdde6238767224296339698a2

1 files changed, 23 insertions, 12 deletions

diff --git a/lib/sqlalchemy/dialects/postgresql/psycopg2.py b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
index 89a63fd47..6d2672bbe 100644
--- a/lib/sqlalchemy/dialects/postgresql/psycopg2.py
+++ b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
@@ -119,18 +119,21 @@ Per-Statement/Connection Execution Options
 -------------------------------------------
 
 The following DBAPI-specific options are respected when used with
-:meth:`.Connection.execution_options`, :meth:`.Executable.execution_options`,
-:meth:`.Query.execution_options`, in addition to those not specific to DBAPIs:
+:meth:`_engine.Connection.execution_options`,
+:meth:`.Executable.execution_options`,
+:meth:`_query.Query.execution_options`,
+in addition to those not specific to DBAPIs:
 
 * ``isolation_level`` - Set the transaction isolation level for the lifespan
-  of a :class:`.Connection` (can only be set on a connection, not a statement
+  of a :class:`_engine.Connection` (can only be set on a connection,
+  not a statement
   or query).   See :ref:`psycopg2_isolation_level`.
 
 * ``stream_results`` - Enable or disable usage of psycopg2 server side
   cursors - this feature makes use of "named" cursors in combination with
   special result handling methods so that result rows are not fully buffered.
   If ``None`` or not set, the ``server_side_cursors`` option of the
-  :class:`.Engine` is used.
+  :class:`_engine.Engine` is used.
 
 * ``max_row_buffer`` - when using ``stream_results``, an integer value that
   specifies the maximum number of rows to buffer at a time.  This is
@@ -153,7 +156,8 @@ Modern versions of psycopg2 include a feature known as
 have been shown in benchmarking to improve psycopg2's executemany()
 performance, primarily with INSERT statements, by multiple orders of magnitude.
 SQLAlchemy allows this extension to be used for all ``executemany()`` style
-calls invoked by an :class:`.Engine` when used with :ref:`multiple parameter
+calls invoked by an :class:`_engine.Engine`
+when used with :ref:`multiple parameter
 sets <execute_multiple>`, which includes the use of this feature both by the
 Core as well as by the ORM for inserts of objects with non-autogenerated
 primary key values, by adding the ``executemany_mode`` flag to
@@ -180,13 +184,15 @@ Possible options for ``executemany_mode`` include:
   semicolon.   This is the same behavior as was provided by the
   ``use_batch_mode=True`` flag.
 
-* ``'values'``- For Core :func:`~.sql.expression.insert` constructs only (including those
+* ``'values'``- For Core :func:`_expression.insert`
+  constructs only (including those
   emitted by the ORM automatically), the ``psycopg2.extras.execute_values``
   extension is used so that multiple parameter sets are grouped into a single
   INSERT statement and joined together with multiple VALUES expressions.   This
   method requires that the string text of the VALUES clause inside the
   INSERT statement is manipulated, so is only supported with a compiled
-  :func:`~.sql.expression.insert` construct where the format is predictable.  For all other
+  :func:`_expression.insert` construct where the format is predictable.
+  For all other
   constructs,  including plain textual INSERT statements not rendered  by the
   SQLAlchemy expression language compiler, the
   ``psycopg2.extras.execute_batch``  method is used.   It is therefore important
@@ -213,7 +219,8 @@ more appropriate::
 .. seealso::
 
     :ref:`execute_multiple` - General information on using the
-    :class:`.Connection` object to execute statements in such a way as to make
+    :class:`_engine.Connection`
+    object to execute statements in such a way as to make
     use of the DBAPI ``.executemany()`` method.
 
 .. versionchanged:: 1.3.7 - Added support for
@@ -299,7 +306,8 @@ actually contain percent or parenthesis symbols; as SQLAlchemy in many cases
 generates bound parameter names based on the name of a column, the presence
 of these characters in a column name can lead to problems.
 
-There are two solutions to the issue of a :class:`.schema.Column` that contains
+There are two solutions to the issue of a :class:`_schema.Column`
+that contains
 one of these characters in its name.  One is to specify the
 :paramref:`.schema.Column.key` for columns that have such names::
 
@@ -312,10 +320,12 @@ Above, an INSERT statement such as ``measurement.insert()`` will use
 ``measurement.c.size_meters > 10`` will derive the bound parameter name
 from the ``size_meters`` key as well.
 
-.. versionchanged:: 1.0.0 - SQL expressions will use :attr:`.Column.key`
+.. versionchanged:: 1.0.0 - SQL expressions will use
+   :attr:`_schema.Column.key`
    as the source of naming when anonymous bound parameters are created
    in SQL expressions; previously, this behavior only applied to
-   :meth:`.Table.insert` and :meth:`.Table.update` parameter names.
+   :meth:`_schema.Table.insert` and :meth:`_schema.Table.update`
+   parameter names.
 
 The other solution is to use a positional format; psycopg2 allows use of the
 "format" paramstyle, which can be passed to
@@ -352,7 +362,8 @@ As discussed in :ref:`postgresql_isolation_level`,
 all PostgreSQL dialects support setting of transaction isolation level
 both via the ``isolation_level`` parameter passed to :func:`.create_engine`,
 as well as the ``isolation_level`` argument used by
-:meth:`.Connection.execution_options`.  When using the psycopg2 dialect, these
+:meth:`_engine.Connection.execution_options`.  When using the psycopg2 dialect
+, these
 options make use of psycopg2's ``set_isolation_level()`` connection method,
 rather than emitting a PostgreSQL directive; this is because psycopg2's
 API-level setting is always emitted at the start of each transaction in any