fronted-backend protocol request, + "select for edit" request

From: "M(dot) Bastin" <marcbastin(at)mindspring(dot)com>
To: pgsql-novice(at)postgresql(dot)org
Subject: fronted-backend protocol request, + "select for edit" request
Date: 2004-07-01 17:47:44
Message-ID: a0610051cbd09f9c7968d@[213.224.114.176]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

I'm not sure if this is a good list to discuss this to make sure it
are good ideas, but here I go.

This is something that has kept bugging me with the frontend-backend protocols:

For the RowDescription "T" and CopyOutResponse "H" messages I'd like
to see a new property that would either contain the total number of
bytes that is going to be sent, or the total number of rows. (Even
only an estimation.) This would allow to implement clean progress
bars in GUI clients. Now you can work around this by doing a
COUNT(*) first, but this is a severe performance hit of course.

Another annoyance is SELECT FOR UPDATE. There should also be
something as SELECT FOR EDIT. The difference being that SELECT FOR
EDIT wouldn't wait for the record to be unlocked but would fail to
access it with an error message giving the user name of the user
who's locking the record. (Then you can implement a dialog like
"Sorry, this record is being edited by Joe. Please try to access it
again later.")

The problem with SELECT FOR UPDATE is that a human user can be
editing and locking a record for 15 minutes or longer, during which
other users who do a SELECT FOR UPDATE on the same record are frozen!
There's a work-around with a tedious query to check whether a given
record is locked prior to accessing it with SELECT FOR UPDATE, but if
something like SELECT FOR EDIT was built in it would be so much
easier and safer to use with future PostgreSQL upgrades!

Thanks for any remarks or suggestions on these ideas,

Marc

Browse pgsql-novice by date

  From Date Subject
Next Message mike g 2004-07-02 04:19:50 Re: Formatting text strings in fields
Previous Message Tom Lane 2004-07-01 17:38:06 Re: .pgpass