On Fri, May 13, 2022 at 11:49:09PM +0200, Laurenz Albe wrote:
> I think that suffers from the same problem: izt sounds like the standard
> allows
> stricter behavior than PostgreSQL.
>
> How about:
>
> The table also shows that PostgreSQL's Repeatable Read implementation
> does not allow phantom reads. That is fine, because the SQL standard only
> specifies which anomalies must <emphasis>not</enphasis> occur at a certain
> isolation level. It is no problem if an implementation provides higher
> guarantees than required.
> The behavior of the available isolation levels is detailed in the
> following subsections.
How is this, attached?
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..112d6ce7a8 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
- must not happen, not which phenomena <emphasis>must</emphasis> happen.
+ does not allow phantom reads. This is acceptable under the SQL
+ standard because the standard specifies which anomalies must
+ <emphasis>not</enphasis> occur at certain isolation levels; higher
+ guarantees are acceptable.
The behavior of the available isolation levels is detailed in the
following subsections.
</para>
