| From: | Rod Taylor <rbt(at)rbt(dot)ca> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Marcus Börger <marcus(dot)boerger(at)post(dot)rwth-aachen(dot)de>, ivan <iv(at)psycho(dot)pl>, Joe Conway <mail(at)joeconway(dot)com>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: php with postgres |
| Date: | 2003-07-22 17:57:37 |
| Message-ID: | 1058896656.46558.87.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Won't that break when we have nested transactions implemented? i.e.
> > begin;commit; would just open a sub transaction and have no effect on the
> > outer transaction...
>
> Yes, it would break. I am not sure how we are going to flag that we
> want to rollback all nested transactions, maybe ROLLBACK ALL.
Shouldn't the results of PQtransactionStatus() override any 'pre-canned'
guess about how to abort a potential transaction since you know the
exact state of the protocol?
If PQprotocolVersion() == 2 then do things the old way (always begin /
rollback).
If either of the above functions are not present (pre-7.4 version of
PostgreSQL) then always begin / rollback.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nailah Ogeer | 2003-07-22 18:00:06 | Checkpoints |
| Previous Message | Darren King | 2003-07-22 17:52:20 | Re: suggestions to improve postgresql suitability for data-mining |