Обсуждение: Make default values bold in Synopsis / bnf diagram

Поиск
Список
Период
Сортировка

Make default values bold in Synopsis / bnf diagram

От
PG Doc comments form
Дата:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/sql-set-transaction.html
Description:

As an example let's take take "BEGIN"
in the Synopsis : 
-------- Start Synopsis for BEGIN --------------------
BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ]

where transaction_mode is one of:

    ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
UNCOMMITTED }
    READ WRITE | READ ONLY
    [ NOT ] DEFERRABLE
-------- End Synopsis for BEGIN --------------------
In this example the words to words "READ COMMITTED", "READ WRITE" should be
bold since they are default values if I execute the statement "BEGIN;" see
the example.

By the way I started in "BEGIN" but here the defaults was not even present
sow I went to "START TRANSACTION but still no indication on default values
but finally in "SET TRANSACTION"
There are default value for "ISOLATION LEVEL" but nothing on default value
for "READ WRITE | READ ONLY" or  "[ NOT ] DEFERRABLE".

Re: Make default values bold in Synopsis / bnf diagram

От
Bruce Momjian
Дата:
On Mon, Dec  2, 2019 at 09:19:32PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/12/sql-set-transaction.html
> Description:
> 
> As an example let's take take "BEGIN"
> in the Synopsis : 
> -------- Start Synopsis for BEGIN --------------------
> BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ]
> 
> where transaction_mode is one of:
> 
>     ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
> UNCOMMITTED }
>     READ WRITE | READ ONLY
>     [ NOT ] DEFERRABLE
> -------- End Synopsis for BEGIN --------------------
> In this example the words to words "READ COMMITTED", "READ WRITE" should be
> bold since they are default values if I execute the statement "BEGIN;" see
> the example.

Uh, I don't think we bold the defaults in the syntax, but if we wanted
to do that, we should do it everywhere.  Is that something we want?  I
am afraid it would just make the default values stand out, which seems
counter-productive.

> By the way I started in "BEGIN" but here the defaults was not even present
> sow I went to "START TRANSACTION but still no indication on default values
> but finally in "SET TRANSACTION"
> There are default value for "ISOLATION LEVEL" but nothing on default value
> for "READ WRITE | READ ONLY" or  "[ NOT ] DEFERRABLE".

Uh, I see in the BEGIN manual page:

    If the isolation level, read/write mode, or deferrable mode is
    specified, the new transaction has those characteristics, as if SET
    TRANSACTION (SET_TRANSACTION(7)) was executed.

and in SET TRANSACTION:

    If the isolation level, read/write mode, or deferrable mode is
    specified, the new transaction has those characteristics, as if SET
    TRANSACTION (SET_TRANSACTION(7)) was executed.

Is "has those characteristics" unclear?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: Make default values bold in Synopsis / bnf diagram

От
"David G. Johnston"
Дата:
On Fri, Dec 20, 2019 at 1:56 PM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Dec  2, 2019 at 09:19:32PM +0000, PG Doc comments form wrote:

> In this example the words to words "READ COMMITTED", "READ WRITE" should be
> bold since they are default values if I execute the statement "BEGIN;" see
> the example.

Uh, I don't think we bold the defaults in the syntax, but if we wanted
to do that, we should do it everywhere.  Is that something we want?  I
am afraid it would just make the default values stand out, which seems
counter-productive.

I originally agreed with theoretically adding <em class="default"> to these but further evaluation below lessens its utility.

> By the way I started in "BEGIN" but here the defaults was not even present
> sow I went to "START TRANSACTION but still no indication on default values
> but finally in "SET TRANSACTION"
> There are default value for "ISOLATION LEVEL" but nothing on default value
> for "READ WRITE | READ ONLY" or  "[ NOT ] DEFERRABLE".

Uh, I see in the BEGIN manual page:

        If the isolation level, read/write mode, or deferrable mode is
        specified, the new transaction has those characteristics, as if SET
        TRANSACTION (SET_TRANSACTION(7)) was executed.

and in SET TRANSACTION:

        If the isolation level, read/write mode, or deferrable mode is
        specified, the new transaction has those characteristics, as if SET
        TRANSACTION (SET_TRANSACTION(7)) was executed.

Is "has those characteristics" unclear?


The OP is complaining about the "is not specified" situation.

One complication here, which is noted on the SET TRANSACTION page, is:

"The session default transaction modes can also be set by setting the configuration parameters default_transaction_isolation, default_transaction_read_only, and default_transaction_deferrable."

So in fact the defaults we'd be highlighting would only be the ones that are shipped since the execution environment may have different defaults.

My take-away is that while the OP may have a valid gripe regarding the documentation and how it presents transactions - learning about the defaults and how to change them - the proposed solution is neither particularly practical nor desirable given that what is default is not something that can be absolutely documented.

It is obvious that transactions are not read only by default and defer-ability seldom comes up and in learning about it one does learn its typical default (not deferred).  And there are numerous references when learning about transaction isolation that the shipped default is read committed.  I don't see this single instance of confusion as a call for the developers to go find a better way to write/organize the documentation.  Specific suggestions are welcome though this one I would say should be turned down.

David J.