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.
