Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNKrM-0003SB-FZ for pgsql-docs@arkaria.postgresql.org; Tue, 29 Sep 2020 19:00:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kNKrL-00035V-9m for pgsql-docs@arkaria.postgresql.org; Tue, 29 Sep 2020 19:00:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNKrL-00035N-49 for pgsql-docs@lists.postgresql.org; Tue, 29 Sep 2020 19:00:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNKrI-0005BU-An for pgsql-docs@lists.postgresql.org; Tue, 29 Sep 2020 19:00:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 08TJ0DkR714874; Tue, 29 Sep 2020 15:00:13 -0400 From: Tom Lane To: Niels Andersen cc: Bruce Momjian , "pgsql-docs@lists.postgresql.org" Subject: Re: Version 13 documentation layout is harder to read than version 12 In-reply-to: References: <160135280918.659.8300614023795573502@wrigleys.postgresql.org> <608344.1601387551@sss.pgh.pa.us> <20200929151620.GA26841@momjian.us> Comments: In-reply-to Niels Andersen message dated "Tue, 29 Sep 2020 18:21:08 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <714872.1601406013.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2020 15:00:13 -0400 Message-ID: <714873.1601406013@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Niels Andersen writes: > 2. Is there a middle ground? > * Version 12 had 6 columns, version 13 has one. > * Could we have fewer columns? What if we had 3 columns: One for = operator or function, one for the details and description, and one for an = example with the results. A lot of these tables *did* have three columns before. They were still to= o wide. See e.g. "Table 9.88 Replication SQL Functions" in the v12 docs. Moreover, in a lot of places functions were just ridiculously under-documented because of the tiny amount of space available. If you compare v12 and v13 closely you'll notice that there's more text for many functions (9.35 Geometric Operators is a handy example); and there's room to add more now, wherever we need to. Note that another reason for making these changes was so that the tables would render in a less-than-completely-unreadable fashion in PDF output, which is a good deal narrower than what most people use for web browser windows (and a good deal less forgiving of overruns, too). But I think it's a net benefit for HTML output as well, in that the output does adapt much better than before to smaller window sizes. Not everybody wants to dedicate their whole screen to Postgres docs. Anyway, a very large amount of effort went into this redesign this past spring, and we already tried a lot of variants, and already went through the predictable complaints within the developer community. I'm disinclined to redesign it again right now. If people are still unhappy in a year or so, maybe there will be some appetite for a revisit. regards, tom lane