On 2020-Feb-12, Tom Lane wrote: > For amusement's sake, attached is a screenshot of what Table 9-33 > looks like in A4 format, with my one-row-per-example patch of > yesterday plus a few manually-added zero-width spaces to break up > the examples. This is the first PDF rendering of that table that > I've seen that I actually like.
I like this. The trick of mkaing the first cell take up two or three rows makes this much clearer and sensible than what I had obtained. > I also attached a screenshot of a segment of Table 9-31, to show > what that layout proposal looks like. It's a little busier, but > it does have the advantage that it's clearer how to apply that > format to operator tables. The "returns <type>" notation isn't used > anywhere in SQL for operators, so I am not in love with the idea of > writing the operator tables that way. Yeah, that's a little less obvious. I just noticed that the operators tables show the operator names but not the input datatypes except in the examples. Perhaps we could use a layout with a cell labelled "signature" (namest=col2 nameend=col3) instead of input types + return types and separate them using → which would look like this: date + integer → date > Also worth noting is that in most function tables, and certainly > in the operator tables, we could make the first column narrower. > The same table with the first column half as wide as the others > is depicted in the last screenshot. (For this particular table, > doing that would require breaking some of the longer function > names such as transaction_timestamp. Not sure whether that's > a net win, but we do have the option.) I like making that column narrower. > One issue that I've found is that the toolchain has no idea that > the table rows are in groups, so it's happy to split a table > across pages with a function's description and/or examples on > a new page. No idea if there's any way around that. Fortunately > it's not an issue in HTML, so maybe we don't have to fix it. My vote goes to postponing a solution to this problem :-) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services