@@ -62,30 +62,30 @@ Keyword parameters accepted by `connect`:
6262 sslrootcrtfile
6363 Root certificate file path given to `ssl.wrap_socket`
6464 sslrootcrlfile
65- Revocation list file path. Currently unused.
65+ Revocation list file path. [Throws a NotSupportedWarning]
6666
67- From here on `pg_con ` will be assumed to exist and serve as the documentation's
67+ From here on `db ` will be assumed to exist and serve as the documentation's
6868Connection instance.
6969
7070Querying
7171--------
7272
73- Querying PostgreSQL is very easy. A query object is created, a
74- `PreparedStatement` instance, using the `query ` method on the connection
73+ Querying PostgreSQL is very easy. A statement object is created, a
74+ `PreparedStatement` instance, using the `prepare ` method on the connection
7575object::
7676
77- >>> my_query = pg_con.query ("SELECT 'hello, world!'")
77+ >>> my_statement = db.prepare ("SELECT 'hello, world!'")
7878
79- This creates a bound query object, so it's only usable on the `pg_con `
79+ This creates a bound statement object, so it's only usable on the `db `
8080connection. While this may seem to be a trifle for some situations, it's very
81- handy to be able to pass around the query object without having to explicitly
81+ handy to be able to pass around the statement object without having to explicitly
8282carry the connection object with it.
8383
8484Now, to execute it::
8585
86- >>> my_results = my_query ()
86+ >>> my_results = my_statement ()
8787
88- Just like executing a function. In this case, invoking `my_query ` will return a
88+ Just like executing a function. In this case, invoking `my_statement ` will return a
8989`Cursor` object to the result set.
9090
9191NOTE: Don't confuse PG-API cursors with DB-API cursors. PG-API cursors are SQL
@@ -117,15 +117,15 @@ As cursors have a couple methods for reading tuples, queries a few methods for
117117executing the prepared statement:
118118
119119 ``__call__(...)``
120- As shown before, query objects can be simply invoked like a function to get a
121- cursor to the query 's results.
120+ As shown before, statement objects can be simply invoked like a function to get a
121+ cursor to the statement 's results.
122122
123123 ``first(...)``
124124 For simple queries, a cursor object can be a bit tiresome to get data from,
125125 consider the data contained in ``my_results``, 'hello world!'. To get at this
126126 data directly from the ``__call__(...)`` method, it looks something like::
127127
128- >>> my_query ().read()[0][0]
128+ >>> my_statement ().read()[0][0]
129129
130130 While it's certainly easy to understand, it can be quite cumbersome and
131131 perhaps even error prone for more complicated queries returing single values.
@@ -145,33 +145,24 @@ executing the prepared statement:
145145 The first row count: When DML--for instance, an INSERT-statement--is executed,
146146 ``first()`` will return the row count returned by the statement as an integer.
147147
148- The result set created by the query determines what is actually returned.
149- Naturally, a query used with ``first()`` should be crafted with these rules in
150- mind.
148+ The result set created by the statement determines what is actually returned.
149+ Naturally, a statement used with ``first()`` should be crafted with these
150+ rules in mind.
151151
152- ``declare(...)``
153- For situations where cursor declaration parameters are needed, the ``declare``
154- method should be used. By default it will create a cursor for the query with
155- hold and with scroll; enabling the cursor's ``seek()`` and ``scroll()``
156- methods to be used. Cursors created in this fashion are a stark contrast from
157- those created by ``__call__()``, as the kind of cursors returned by
158- ``__call__()`` are optimized for fast, sequential row retrivial, whereas
159- declared cursors are built to guarantee the positioning.
160-
161- Query objects can take parameters. To do this, the query must be defined using
152+ Statement objects can take parameters. To do this, the statement must be defined using
162153PostgreSQL's positional parameter notation. ``$1``, ``$2``, ``$3``, etc. If the
163- query object ``my_query `` were to be re-written to take a parameter, it would be
154+ statement object ``my_statement `` were to be re-written to take a parameter, it would be
164155done simply::
165156
166- >>> my_query = pg_con.query ("SELECT $1")
157+ >>> my_statement = db.prepare ("SELECT $1")
167158
168159And, re-create the ``my_cursor``::
169160
170- >>> my_cursor = my_query ('hello, world!')
161+ >>> my_cursor = my_statement ('hello, world!')
171162
172163It's that easy. And using ``first()``::
173164
174- >>> 'hello, world!' == my_query .first('hello, world!')
165+ >>> 'hello, world!' == my_statement .first('hello, world!')
175166 True
176167
177168Inserting
@@ -184,6 +175,5 @@ Copying
184175Transacting
185176-----------
186177
187-
188178Setting
189179-------
0 commit comments