[DB-SIG] Some obscurity with paramstyle

James Henstridge james at jamesh.id.au
Wed Jul 20 04:46:38 CEST 2011

On Mon, Jul 18, 2011 at 5:28 PM, Federico Di Gregorio
<federico.digregorio at dndg.it> wrote:
> On 18/07/11 11:25, James Henstridge wrote:
>> If all adapters that support transactions function like that, then I
>> think it would be sensible to require them to raise an error in that
>> case.  If they don't raise an error, you know that someone somewhere
>> is going to write code like the following:
>>     with transaction:
>>         # do stuff
>>         with transaction:
>>             # do more stuff
>> ... and wonder why things break.
> This can make sense for backends that support check points
> (subtransactions). PostgreSQL is an example (even if we don't yet
> support checkpoints in psycopg).

While it is definitely possible to simulate some kind of
"sub-transaction" through the use of save points, I'm not sure whether
it is actually a good idea to magically substitute one for the other.

One feature of committing a transaction is that it makes the work has
been saved permanently and is available to other connections, which
won't be the case with a save point based sub-transaction.  If I wrote
some code that relied on those semantics (e.g. one that posts a
message to another process after completing its work), then it would
be an error to call it from within transaction context and I'd want to
see an error explaining the fact.

There probably are uses where a recursive transaction
decorator/context manager might be useful, but I don't think it is
necessarily something users would want by default.


More information about the DB-SIG mailing list