diff options
| -rw-r--r-- | doc/src/connection.rst | 2 | ||||
| -rw-r--r-- | doc/src/faq.rst | 4 | ||||
| -rw-r--r-- | doc/src/pool.rst | 2 | ||||
| -rw-r--r-- | doc/src/usage.rst | 26 |
4 files changed, 17 insertions, 17 deletions
diff --git a/doc/src/connection.rst b/doc/src/connection.rst index 235155b..577517e 100644 --- a/doc/src/connection.rst +++ b/doc/src/connection.rst @@ -18,7 +18,7 @@ The ``connection`` class Connections are created using the factory function `~psycopg2.connect()`. - Connections are thread safe and can be shared among many thread. See + Connections are thread safe and can be shared among many threads. See :ref:`thread-safety` for details. .. method:: cursor([name] [, cursor_factory] [, withhold]) diff --git a/doc/src/faq.rst b/doc/src/faq.rst index e7fe76f..3296cd8 100644 --- a/doc/src/faq.rst +++ b/doc/src/faq.rst @@ -18,7 +18,7 @@ Why does `!psycopg2` leave database sessions "idle in transaction"? :sql:`SELECT`. The transaction is not closed until an explicit `~connection.commit()` or `~connection.rollback()`. - If you are writing a long-living program, you should probably ensure to + If you are writing a long-living program, you should probably make sure to call one of the transaction closing methods before leaving the connection unused for a long time (which may also be a few seconds, depending on the concurrency level in your database). Alternatively you can use a @@ -37,7 +37,7 @@ I receive the error *current transaction is aborted, commands ignored until end Why do I get the error *current transaction is aborted, commands ignored until end of transaction block* when I use `!multiprocessing` (or any other forking system) and not when use `!threading`? Psycopg's connections can't be shared across processes (but are thread - safe). If you are forking the Python process ensure to create a new + safe). If you are forking the Python process make sure to create a new connection in each forked child. See :ref:`thread-safety` for further informations. diff --git a/doc/src/pool.rst b/doc/src/pool.rst index 45af409..32bca54 100644 --- a/doc/src/pool.rst +++ b/doc/src/pool.rst @@ -10,7 +10,7 @@ Creating new PostgreSQL connections can be an expensive operation. This module offers a few pure Python classes implementing simple connection pooling -directly into the client application. +directly in the client application. .. class:: AbstractConnectionPool(minconn, maxconn, \*args, \*\*kwargs) diff --git a/doc/src/usage.rst b/doc/src/usage.rst index dbc7ec8..e0595d2 100644 --- a/doc/src/usage.rst +++ b/doc/src/usage.rst @@ -39,7 +39,7 @@ basic commands:: >>> conn.close() -The main entry point of Psycopg are: +The main entry points of Psycopg are: - The function `~psycopg2.connect()` creates a new database session and returns a new `connection` instance. @@ -90,7 +90,7 @@ is converted into the SQL command:: Named arguments are supported too using :samp:`%({name})s` placeholders. Using named arguments the values can be passed to the query in any order and -many placeholder can use the same values:: +many placeholders can use the same values:: >>> cur.execute( ... """INSERT INTO some_table (an_int, a_date, another_date, a_string) @@ -165,9 +165,9 @@ hang it onto your desk. .. _SQL injection: http://en.wikipedia.org/wiki/SQL_injection .. __: http://xkcd.com/327/ -Psycopg can `convert automatically Python objects into and from SQL -literals`__: using this feature your code will result more robust and -reliable. It is really the case to stress this point: +Psycopg can `automatically convert Python objects to and from SQL +literals`__: using this feature your code will be more robust and +reliable. We must stress this point: .. __: python-types-adaptation_ @@ -290,8 +290,8 @@ the SQL string that would be sent to the database. emit :sql:`bytea` fields. Starting from Psycopg 2.4.1 the format is correctly supported. If you use a previous version you will need some extra care when receiving bytea from PostgreSQL: you must have at least - the libpq 9.0 installed on the client or alternatively you can set the - `bytea_output`__ configutation parameter to ``escape``, either in the + libpq 9.0 installed on the client or alternatively you can set the + `bytea_output`__ configuration parameter to ``escape``, either in the server configuration file or in the client session (using a query such as ``SET bytea_output TO escape;``) before receiving binary data. @@ -444,7 +444,7 @@ the connection or globally: see the function .. note:: - In Python 2, if you want to receive uniformly all your database input in + In Python 2, if you want to uniformly receive all your database input in Unicode, you can register the related typecasters globally as soon as Psycopg is imported:: @@ -526,7 +526,7 @@ older versions). long-running programs, if no further action is taken, the session will remain "idle in transaction", a condition non desiderable for several reasons (locks are held by the session, tables bloat...). For long lived - scripts, either ensure to terminate a transaction as soon as possible or + scripts, either make sure to terminate a transaction as soon as possible or use an autocommit connection. A few other transaction properties can be set session-wide by the @@ -634,7 +634,7 @@ Thread and process safety The Psycopg module and the `connection` objects are *thread-safe*: many threads can access the same database either using separate sessions and -creating a `!connection` per thread or using the same using the same +creating a `!connection` per thread or using the same connection and creating separate `cursor`\ s. In |DBAPI|_ parlance, Psycopg is *level 2 thread safe*. @@ -648,7 +648,7 @@ the same connection, all the commands will be executed in the same session The above observations are only valid for regular threads: they don't apply to forked processes nor to green threads. `libpq` connections `shouldn't be used by a forked processes`__, so when using a module such as `multiprocessing` or a -forking web deploy method such as FastCGI ensure to create the connections +forking web deploy method such as FastCGI make sure to create the connections *after* the fork. .. __: http://www.postgresql.org/docs/9.0/static/libpq-connect.html#LIBPQ-CONNECT @@ -699,7 +699,7 @@ examples. Access to PostgreSQL large objects ---------------------------------- -PostgreSQL offers support to `large objects`__, which provide stream-style +PostgreSQL offers support for `large objects`__, which provide stream-style access to user data that is stored in a special large-object structure. They are useful with data values too large to be manipulated conveniently as a whole. @@ -734,7 +734,7 @@ Two-Phase Commit protocol support Psycopg exposes the two-phase commit features available since PostgreSQL 8.1 implementing the *two-phase commit extensions* proposed by the |DBAPI|. -The |DBAPI| model of two-phase commit is inspired to the `XA specification`__, +The |DBAPI| model of two-phase commit is inspired by the `XA specification`__, according to which transaction IDs are formed from three components: - a format ID (non-negative 32 bit integer) |