>>> Simon Riggs <si...@2ndquadrant.com> wrote: > The SQL Standard specifically names this error as thrown when "it > detects the inability to guarantee the serializability of two or more > concurrent SQL-transactions". Now that really should only apply when > running with SERIALIZABLE transactions, I disagree. Database integrity could not be guaranteed without detection of conflicting modification in READ COMMITTED on up, and this is the normal means of indicating these problems. > but I grant you the standard doesn't explicitly say that. I think that's intentional. > You give me the strange sense that you want this because of some quirk > in your software, rather than an overwhelming desire to see these two > situations described the same. Well, we are very unlikely to ever use this feature, so it's not really something I care about for us; it just struck me that there may be others that care about categorizing errors accurately according the the SQL standard, and that what you were describing sounded like a new type of serialization failure in the PostgreSQL environment, and should be classified that way. The primary quirkiness of our software is that it needs to be able to run with a number of different database products, and we do want to take advantage of whatever information is available in a portable format. This is not the only standard SQLSTATE we look for and handle appropriately for the documented meaning, but it is an important one, as it has simplified application programming and reduced the confusing error messages which reach our end users. > I guess making it that SQLSTATE would make it simpler to understand why > the error occurs and also how to handle it (i.e. resubmit). Precisely. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers