On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote:
> They never use the word anomaly (or its plural) in the standard
> (even though it is prevalent in the academic literature). See my
> earlier email for examples of how the standard describes the issue,
> but basically it just boils down to saying that the effects of
> concurrent execution of a set of serializable transactions must be
> consistent with some one-at-a-time execution order. We could
> perhaps have the column header say "Non-Serializable Behavior" or
> some such; but I think we need to define whatever term we use for
> the new column header.
I don't think we can define the column as a negative, e.g. "Non-".
> >> Pondering whether something like: "Possible (not in PG)" and
> >> avoiding the additional rows would make reading the table
> >> easier.
> >
> > Uh, that's an idea. I thought visually having two separate lines
> > was cleaner.
>
> I think one row per transaction isolation level, with three
> possible values per cell, would be the cleanest. I have been
> trying to think of alternatives for the three values, but have not
> come up with anything better than David's suggestion.
Well, then "Possible" would refer to the SQL standard behavior, which
seems kind of an odd thing to emphasize there. The field really needs
to be "SQL-standard possible, PostgreSQL not possible", but that is too
long. This is why I split it into separate lines. We could try
"Possible (SQL standard), Not possible (PostgreSQL)".
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
