Tom,
Thanks for your response. I've considered you comments and I've been
doing some experimenting with concurrent record updates. I now see what
you mean in your comment. I've been executing all the queries using
PQexec. As you well know, PQexec just sits and waits when another
transaction has hold of the row. I'm wondering if I should use the
Asynchronous Query routines to manage this. I've got to be able to get
feedback to the user and give them the ability to abort the transaction.
Based on what I've been reading it seems the the Asynchronous routines
would work. What is your response to this? Also, I can't find any code
examples at all on how to implement the routines. I can find some
limited discussions about it, but no examples. I could figure it all out
with trial and error but would like to skip that if possible. Do you
know where I can find some code examples?
Thanks...
Tom Lane wrote:
>Terry Lee Tucker <terry@esc1.com> writes:
>
>
>>[snip]
>>1. Does this model make sense based on your work with libpq-fe and
>>postgres?
>>
>>
>
>Yes, it looks pretty standard. But you need to think harder about
>exactly what you intend to do when two people try to edit the same
>record concurrently. ("Use a cursor" does not answer that question
>at all.) That's a bit off-topic for pgsql-interfaces though; I'd
>recommend discussing it in pgsql-sql.
>
>
>
>>2. We are only using a binary cursor for the edit operation. Does
>>this make sense?
>>
>>
>
>Not really. I'd not bother with binary cursors at all. You're just
>opening yourself up to portability problems, and you're not saving
>anything meaningful when you're fetching just one row.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>
>
--
Sparta, NC 28675 USA
336.372.6812
http://www.esc1.com
