My initial thought is that the driver must pass the executemany
parameters on to the server without changing the order of the
parameters. Maybe that should be explicitly stated in the spec. Once
the server has the parameters then I think the behaviour becomes DBMS
dependent. I guess my philosophy i
Sorry I'm a bit late to all of this. Here's what pg8000 does, together with
what it sends to PostgreSQL:
cursor.execute("SELECT :1, :2", (6, 0))
# Sent to server: "SELECT $1, $2"
# Result: ['6', '0']
cursor.execute("SELECT :2, :1", (6, 0))
# Sent to server: "SELECT $2, $1"
# Result: ['0', '6']
Hello all, with pg8000 if autocommit is turned on while a transaction is in
progress, the autocommit behaviour only takes effect after the current
transaction has been explicitly committed or rolled back. Of the options
given, I'd go for option 1, raising an exception. I don't like the idea of
SQL
Mike, I agree. You quote:
"The first time you pass a statement to the cursor's execute() method, it
prepares the
statement. For subsequent invocations of execute(), the preparation phase is
skipped if the statement is the same.”
This is basically what pg8000 does but I've found you need a couple
On the question of extending the DB-API to accommodate prepared
statements, from my narrow point of view as a maintainer of pg8000
it's unnecessary, as pg8000 uses prepared statements for everything
anyway. In later versions of Postgres, the query plan is potentially
updated every time a prepared s
Hi, I would say that a user of your driver would expect the full
number of rows specified in fetchmany to be returned (if the rows are
there). So my view would be to stick to PEP 249 in this case.
Cheers,
Tony.
On 11 June 2014 02:06, Daniel Lenski wrote:
> I'm writing a DBAPI module for a custo
Hi Daniele, the latest release of pg8000 (1.9.7) has (experimental)
support for prepared statements, but takes an implicit approach rather
than an explicit one. In the connect() function there's a boolean
use_cache parameter which tells pg8000 to cache prepared statements,
keyed against the SQL que
What sort of thing do you have in mind? Perhaps something where the
execute() method returns immediately, and a callback function is called
when the query is complete?
This could be implemented in a library on top of DB-API. But should it be
part of the spec?
Cheers,
Tony.
On 25 October 2013 0
On 25 October 2013 11:31, Daniele Varrazzo wrote:
> On Thu, Oct 24, 2013 at 10:57 AM, Tony Locke wrote:
> > Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension
> into
> > the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn'
Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension
into the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn't
see anything. The reason I ask is that I'm noticing on PG8000 that the time
taken to execute the warn() for each call to next() is significant for
iterati
ity. Postgres is pretty much alone in
> using numeric, where several other popular databases all use qmark.
> The most important reason for leaving the .paramstyle attribute in place
> is so that Postgres applications need not be re-written -- we assume that
> anyone who writes a P
Hi, I'm a contributor to the PG8000 Postgres driver:
https://github.com/mfenniak/pg8000/tree/py3
Having read the interesting DBAPI 3.0 wiki page:
https://wiki.python.org/moin/DbApi3
I thought I'd give a suggestion for unified parameters. Apologies if
this has been suggested before, I did have a
12 matches
Mail list logo
