>>> Simon Riggs <simon(at)2ndQuadrant(dot)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