Date: Sat, 25 Apr 2015 20:47:47 +0000 (UTC)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Peter Eisentraut <peter_e@gmx.net>,
 "pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
Message-ID: <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150425200255.GD17791@momjian.us>
References: <20150425200255.GD17791@momjian.us>
Subject: Re: Add a new table for Transaction Isolation?
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 2606
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote:

>> 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-".

Yeah, that would tend to add to confusion.  The basic issue is
whether there are any one-at-a-time orders of execution that could
yield the same results, or whether there is a cycle in an attempt
to graph such an order.  "Cycles in Apparent Order of Execution"
would be accurate, but it's kinda long, and possibly too arcane.

>>>> =E2=80=8BPondering 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)".

Yeah, I was searching for some wording that conveyed that the
standard *allowed* an implementation to present such phenomena at
the isolation level versus whether the PostgreSQL implementation
could *actually* present such phenomena.  In struggling to come up
with an analogy, the best I can do is that it's like each person
fishing for rainbow trout in Wisconsin is *allowed* to keep it if
it is at least 26 inches long; some people will do so, and some
catch and release.  Regulations say that it is possible to keep it=20
(and not be in violation of the rules), but you are not required to=20
keep it.  For REPEATABLE READ, the SQL standard says that any
product would be *allowed* to have phantom reads, but is not
*required* to; we, as a community, choose not to.


Maybe something like "Prohibited", "Allowed but not Possible", and
"Possible"?  That would take a little explaining above, since our
documentation's table would be deviating from the standard's table
in its word choice.


--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs