At 09:13 PM 8/10/00 -0700, Tim Perdue wrote:
>Ben Adida wrote:
>> begin transaction
>> select balance from accounts where account_id=2 for update
>>
>> will select the balance and lock the row for account #2
>> You can then perform some math on the balance, and do something like:
>>
>> update accounts set balance= $new_balance where account_id=2
>> end transaction
>>
>
>Great - I assume end transaction is going to do a commit. If you don't
>do an end transaction and you don't issue a rollback... I assume it
>rolls back?
It is best not to assume, and to do so explicitly. I base this on the
theory that you ought to know what your code does, and what it did to
get there.
(end transaction is indeed "commit", you can use "commit" if you prefer).
>This is pretty slick - over the last month or so I've come up with about
>8 different places where I really wish I had transactions/rollbacks on
>SourceForge.
Yes. That's the realization one comes to when working on complex database
apps.
>Also running into lots of places where I really, really
>wish I had fscking subselects...
As someone who uses Oracle, I feel the same way, but Postgres doesn't
make me feel that way nearly as often as MySQL would :)
(and actually, Oracle's outer join syntax requires subselects if you are
to mix and match inner and outer joins and control the priority of execution
order - which the vastly superior SQL92 syntax solves in a reasonably
elegant manner).
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.