Modified: trunk/docs/contents/changelog.rst (1014 => 1015)
--- trunk/docs/contents/changelog.rst 2019-05-19 18:39:37 UTC (rev 1014)
+++ trunk/docs/contents/changelog.rst 2019-06-07 17:16:43 UTC (rev 1015)
@@ -25,7 +25,7 @@
an error if the result does not have exactly one row.
- New methods query.dictiter(), query.namediter() and query.scalariter()
returning the same values as query.dictresult(), query.namedresult()
- and query.salarresult(), but as iterables instead of lists. This avoids
+ and query.scalarresult(), but as iterables instead of lists. This avoids
creating a Python list of all results and can be slightly more efficient.
- Removed pg.get/set_namedresult. You can configure the named tuples
factory with the pg.set_row_factory_size() function and change the
Modified: trunk/docs/contents/pg/adaptation.rst (1014 => 1015)
--- trunk/docs/contents/pg/adaptation.rst 2019-05-19 18:39:37 UTC (rev 1014)
+++ trunk/docs/contents/pg/adaptation.rst 2019-06-07 17:16:43 UTC (rev 1015)
@@ -61,28 +61,28 @@
When you use the higher level methods of the classic :mod:`pg` module like
:meth:`DB.insert()` or :meth:`DB.update()`, you don't need to care about
adaptation of parameters, since all of this is happening automatically behind
-the scenes. You only need to consider this issue when creating SQL commands
-manually and sending them to the database using the :meth:`DB.query` method.
-
-Imagine you have created a user login form that stores the login name as
-*login* and the password as *passwd* and you now want to get the user
-data for that user. You may be tempted to execute a query like this::
-
+the scenes. You only need to consider this issue when creating SQL commands
+manually and sending them to the database using the :meth:`DB.query` method.
+
+Imagine you have created a user login form that stores the login name as
+*login* and the password as *passwd* and you now want to get the user
+data for that user. You may be tempted to execute a query like this::
+
>>> db = pg.DB(...)
>>> sql = "SELECT * FROM user_table WHERE login = '%s' AND passwd = '%s'"
>>> db.query(sql % (login, passwd)).getresult()[0]
-
-This seems to work at a first glance, but you will notice an error as soon as
-you try to use a login name containing a single quote. Even worse, this error
-can be exploited through so-called "SQL injection", where an attacker inserts
-malicious SQL statements into the query that you never intended to be executed.
-For instance, with a login name something like ``' OR ''='`` the attacker could
-easily log in and see the user data of another user in the database.
-
-One solution for this problem would be to cleanse your input of "dangerous"
-characters like the single quote, but this is tedious and it is likely that
-you overlook something or break the application e.g. for users with names
-like "D'Arcy". A better solution is to use the escaping functions provided
+
+This seems to work at a first glance, but you will notice an error as soon as
+you try to use a login name containing a single quote. Even worse, this error
+can be exploited through so-called "SQL injection", where an attacker inserts
+malicious SQL statements into the query that you never intended to be executed.
+For instance, with a login name something like ``' OR ''='`` the attacker could
+easily log in and see the user data of another user in the database.
+
+One solution for this problem would be to cleanse your input of "dangerous"
+characters like the single quote, but this is tedious and it is likely that
+you overlook something or break the application e.g. for users with names
+like "D'Arcy". A better solution is to use the escaping functions provided
by PostgreSQL which are available as methods on the :class:`DB` object::
>>> login = "D'Arcy"
@@ -161,13 +161,13 @@
>>> db.query_formatted(sql, (login,), inline=False).getresult()[0]
In real world examples you will rarely have to cast your parameters like that,
-since in an INSERT statement or a WHERE clause comparing the parameter to a
-table column the data type will be clear from the context.
-
-When binding the parameters to a query, PyGreSQL not only adapts the basic
-types like ``int``, ``float``, ``bool`` and ``str``, but also tries to make
-sense of Python lists and tuples.
-
+since in an INSERT statement or a WHERE clause comparing the parameter to a
+table column, the data type will be clear from the context.
+
+When binding the parameters to a query, PyGreSQL not only adapts the basic
+types like ``int``, ``float``, ``bool`` and ``str``, but also tries to make
+sense of Python lists and tuples.
+
Lists are adapted as PostgreSQL arrays::
>>> params = dict(array=[[1, 2],[3, 4]])
@@ -174,8 +174,8 @@
>>> db.query_formatted("SELECT %(array)s::int[]", params).getresult()[0][0]
[[1, 2], [3, 4]]
-Note that again we only need to cast the array parameter or use inline
-parameters because this simple query does not provide enough context.
+Note that again we need to cast the array parameter or use inline parameters
+only because this simple query does not provide enough context.
Also note that the query gives the value back as Python lists again. This
is achieved by the typecasting mechanism explained in the next section.
@@ -219,14 +219,14 @@
>>> row = dict(item=inventory_item('fuzzy dice', 42, 1.99), count=1000)
>>> db.insert('on_hand', row)
- {'count': 1000, 'item': inventory_item(name='fuzzy dice',
- supplier_id=42, price=Decimal('1.99'))}
-
-Perhaps we want to use custom Python classes instead of named tuples to hold
-our values::
-
- >>> class InventoryItem:
- ...
+ {'count': 1000, 'item': inventory_item(name='fuzzy dice',
+ supplier_id=42, price=Decimal('1.99'))}
+
+Perhaps we want to use custom Python classes instead of named tuples to hold
+our values::
+
+ >>> class InventoryItem:
+ ...
... def __init__(self, name, supplier_id, price):
... self.name = name
... self.supplier_id = supplier_id
Modified: trunk/docs/contents/pg/db_wrapper.rst (1014 => 1015)
--- trunk/docs/contents/pg/db_wrapper.rst 2019-05-19 18:39:37 UTC (rev 1014)
+++ trunk/docs/contents/pg/db_wrapper.rst 2019-06-07 17:16:43 UTC (rev 1015)
@@ -493,9 +493,9 @@
If you set *inline* to True or don't pass any parameters, the command string
can also include multiple SQL commands (separated by semicolons). You will
-only get the return value for the last command in this case.
+only get the result for the last command in this case.
-Note that the adaption and conversion of the parameters causes a certain
+Note that the adaptation and conversion of the parameters causes a certain
performance overhead. Depending on the type of values, the overhead can be
smaller for *inline* queries or if you pass the types of the parameters,
so that they don't need to be guessed from the values. For best performance,
Modified: trunk/pg.py (1014 => 1015)
--- trunk/pg.py 2019-05-19 18:39:37 UTC (rev 1014)
+++ trunk/pg.py 2019-06-07 17:16:43 UTC (rev 1015)
@@ -1939,7 +1939,7 @@
"""Create a prepared SQL statement.
This creates a prepared statement for the given command with the
- the given name for later execution with the query_prepared() method.
+ given name for later execution with the query_prepared() method.
The name can be empty to create an unnamed statement, in which case
any pre-existing unnamed statement is automatically replaced;
