The company I work for is using PyGreSQL in a number of production
systems. For various historical reasons, they're currently using
a number of very evil hacks around the official pgdb module, and I'm
currently investigating whether we can do the same things in a more
maintainable fashion.

The problems we have with pgdb are:

    - pgdb converts results to native Python types, which has a big
      performance hit. We get around this by manipulating the pgdb
      cursor object's __source attribute directly.
    - As per DB-API 2.0, every cursor has implicit transactions, which
      breaks our (admittedly badly-written) code. We get around this by
      hand-editing the pgdb.py file on every server we set up (!).

I've been looking at the various interfaces PyGreSQL offers, and it
seems that the best course of action would be to use pg.DB() as the
equivalent of our current 'connection' objects, and connection.source()
as the equivalent of our current cursor objects (we don't call the pgdb
DB-API functions directly, so the fact that DB and source objects don't
implement the DB-API methods does not worry me).

The only thing that *does* worry me is that although the DB.source()
method doesn't have any leading underscores, it's not mentioned in the
official pg module's documentation. Is DB.source() really a public API
that we can rely on being supported and working for at least a few
years? If not, is there some other cursor-style API that I could build
on that would be supported?
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql

Reply via email to