mirror of
https://github.com/psycopg/psycopg2.git
synced 2025-02-07 12:50:32 +03:00
Fixed some typos
This commit is contained in:
parent
961b4eedc5
commit
1a7a12c833
|
@ -104,7 +104,7 @@ Type casting of SQL types into Python values
|
|||
|
||||
PostgreSQL objects read from the database can be adapted to Python objects
|
||||
through an user-defined adapting function. An adapter function takes two
|
||||
argments: the object string representation as returned by PostgreSQL and the
|
||||
arguments: the object string representation as returned by PostgreSQL and the
|
||||
cursor currently being read, and should return a new Python object. For
|
||||
example, the following function parses a PostgreSQL ``point`` into the
|
||||
previously defined ``Point`` class::
|
||||
|
@ -164,7 +164,7 @@ Asynchronous queries
|
|||
|
||||
.. warning::
|
||||
|
||||
Async quaeries are not enabled for 2.0
|
||||
Asynchronous queries are not enabled for 2.0
|
||||
|
||||
.. todo::
|
||||
|
||||
|
@ -183,7 +183,7 @@ doomed to fail (and raise an exception) until the original cursor (the one
|
|||
executing the query) complete the asynchronous operation. This can happen in
|
||||
a number of different ways:
|
||||
|
||||
1) one of the :obj:`.fetch*()` methods is called, effectively blocking untill
|
||||
1) one of the :obj:`.fetch*()` methods is called, effectively blocking until
|
||||
data has been sent from the backend to the client, terminating the query.
|
||||
|
||||
2) :meth:`connection.cancel` is called. This method tries to abort the
|
||||
|
@ -204,7 +204,7 @@ Note that calling :obj:`.execute()` two times in a row will not abort the
|
|||
former query and will temporarily go to synchronous mode until the first of
|
||||
the two queries is executed.
|
||||
|
||||
Cursors now have some extra methods that make them usefull during
|
||||
Cursors now have some extra methods that make them useful during
|
||||
asynchronous queries:
|
||||
|
||||
:meth:`cursor.fileno`
|
||||
|
|
|
@ -121,7 +121,7 @@ The ``connection`` class
|
|||
.. method:: get_transaction_status()
|
||||
|
||||
Return the current session transaction status as an integer. Symbolic
|
||||
constants for the vaules are defined in the module
|
||||
constants for the values are defined in the module
|
||||
:mod:`psycopg2.extensions`: see :ref:`transaction-status-constants`
|
||||
for the available values.
|
||||
|
||||
|
@ -131,7 +131,7 @@ The ``connection`` class
|
|||
|
||||
.. attribute:: protocol_version
|
||||
|
||||
A read-ony integer representing frontend/backend protocol being used.
|
||||
A read-only integer representing frontend/backend protocol being used.
|
||||
It can be 2 or 3.
|
||||
|
||||
.. seealso:: libpq docs for `PQprotocolVersion()`__ for details.
|
||||
|
|
|
@ -45,7 +45,7 @@ The ``cursor`` class
|
|||
|execute*|_ methods yet.
|
||||
|
||||
The type_code can be interpreted by comparing it to the Type Objects
|
||||
specified in the section :ref:`type-objects-and-costructors`.
|
||||
specified in the section :ref:`type-objects-and-constructors`.
|
||||
|
||||
.. method:: close()
|
||||
|
||||
|
@ -171,13 +171,13 @@ The ``cursor`` class
|
|||
|
||||
.. _fetch*:
|
||||
|
||||
The followig methods are used to read data from the database after an
|
||||
The following methods are used to read data from the database after an
|
||||
:meth:`execute()` call.
|
||||
|
||||
.. note::
|
||||
|
||||
:class:`cursor` objects are iterable, so, instead of calling
|
||||
explicitely :meth:`fetchone()` in a loop, the object itself can be
|
||||
explicitly :meth:`fetchone()` in a loop, the object itself can be
|
||||
used::
|
||||
|
||||
>>> cur.execute("SELECT * FROM test;")
|
||||
|
@ -286,7 +286,7 @@ The ``cursor`` class
|
|||
affected (for DML statements like ``UPDATE`` or ``INSERT``).
|
||||
|
||||
The attribute is -1 in case no |execute*| has been performed on
|
||||
the cursor or the rowcount of the last operation is cannot be
|
||||
the cursor or the row count of the last operation if it can't be
|
||||
determined by the interface.
|
||||
|
||||
.. note::
|
||||
|
|
|
@ -163,7 +163,7 @@ This is the exception inheritance layout:
|
|||
.. _StandardError: http://docs.python.org/library/exceptions.html#exceptions.StandardError
|
||||
|
||||
|
||||
.. _type-objects-and-costructors:
|
||||
.. _type-objects-and-constructors:
|
||||
|
||||
Type Objects and Constructors
|
||||
-----------------------------
|
||||
|
|
|
@ -143,7 +143,7 @@ is converted into the SQL command::
|
|||
|
||||
Named arguments are supported too using ``%(name)s`` placeholders. Using named
|
||||
arguments the values can be passed to the query in any order and many
|
||||
placeholder can use the the same values::
|
||||
placeholder can use the same values::
|
||||
|
||||
>>> cur.execute(
|
||||
... """INSERT INTO some_table (an_int, a_date, another_date, a_string)
|
||||
|
@ -296,7 +296,7 @@ all the returned records, transferring them to the client process. If the
|
|||
query returned an huge amount of data, a proportionally large amount of memory
|
||||
will be allocated by the client.
|
||||
|
||||
If the dataset is too large to be pratically handled on the client side, it is
|
||||
If the dataset is too large to be practically handled on the client side, it is
|
||||
possible to create a *server side* cursor. Using this kind of cursor it is
|
||||
possible to transfer to the client only a controlled amount of data, so that a
|
||||
large dataset can be examined without keeping it entirely in memory.
|
||||
|
|
Loading…
Reference in New Issue
Block a user