On Thu, Dec 17, 2009 at 1:12 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.com> wrote: > >> I don't think that's any clearer, though it is more disparaging. >> :-) > > It's certainly not my goal to knock PostgreSQL. The precise > conditions in which an UPDATE or DELETE can view an inconsistent > database state (and therefore potentially persist something based on > that inconsistent state) are that it has a FROM clause and/or > subqueries which reference data changed by a concurrent database > transaction which also affects rows which are targets of the UPDATE > or DELETE. Precise descriptions of problem circumstances seem more > useful to developers than vague statements like "it's usually good > enough, except when it isn't." > > If an accurate description of the behavior is considered > disparaging, perhaps it's the behavior which should change, not just > the description of it. Since I never use READ COMMITTED for > updates, I'm not going to weigh in on whether this is a big enough > problem to merit the effort and overhead of a different > implementation; I'm just suggesting we should put the information > out there more explicitly. My wording was still a little on the > vague side, in an attempt to keep it short; perhaps that was a > mistake.
Don't get me wrong, I don't love the current behavior. (I don't have a competing proposal either.) But I think we want to describe it with precision, because there are also many cases where _it works fine_. Telling people when it works and when it doesn't work is a lot more useful than attempting to qualitatively estimate how good or bad it is. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
