]> git.ipfire.org Git - thirdparty/psycopg.git/commitdiff
Fixed COPY statement suggesting it accepts parameters
authorDaniele Varrazzo <daniele.varrazzo@gmail.com>
Wed, 2 Dec 2020 19:03:15 +0000 (19:03 +0000)
committerDaniele Varrazzo <daniele.varrazzo@gmail.com>
Wed, 2 Dec 2020 19:03:15 +0000 (19:03 +0000)
It was, it just didn't work... :P

docs/from_pg2.rst

index a954e17d6b0ff4a068fe851c846f831d27544dbd..ca3d87506339b101c402484e6b8933c3517935e7 100644 (file)
@@ -82,12 +82,12 @@ type you should check the :ref:`adaptation` topic.
 Copy is no more file-based
 --------------------------
 
-`psycopg2` exposes :ref:`a few copy methods <pg2:copy>` to interact with
+`!psycopg2` exposes :ref:`a few copy methods <pg2:copy>` to interact with
 PostgreSQL :sql:`COPY`. The interface doesn't make easy to load
 dynamically-generated data to the database.
 
 There is now a single `~psycopg3.Cursor.copy()` method, which is similar to
-`~cursor.copy_expert()`, which accepts parameters like `!execute()` and
+`!psycopg2` `!copy_expert()` in accepting a free-form :sql:`COPY` command and
 returns an object to read/write data, block-wise or record-wise. The different
 usage pattern also enables :sql:`COPY` to be used in async interactions.
 
@@ -100,7 +100,7 @@ See :ref:`copy` for the details.
 -------------------
 
 When the connection is used as context manager, at the end of the context
-the connection will be closed. In psycopg2 only the transaction is closed,
+the connection will be closed. In `!psycopg2` only the transaction is closed,
 so a connection can be used in several contexts, but the behaviour is
 surprising for people used to several other Python classes wrapping
 resources, such as files.