Re: Poll: are people okay with function/operator table redesign?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Steven Pousty <steve(dot)pousty(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Pierre Giraud <pierre(dot)giraud(at)dalibo(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Poll: are people okay with function/operator table redesign?
Date: 2020-04-17 00:25:09
Message-ID: 17560.1587083109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I like your v2 even better. If it becomes possible to remove or soften
> the "inter-row" horizontal line with CSS tricks afterwards, that would
> be swell, but even without that, I cast my vote to using this table
> format.

I eventually figured out that the approved way to do per-table-entry
customization is to attach "role" properties to the DocBook elements,
and then key off the role names in applying formatting changes in
the customization layer. So attached is a v3 that handles the desired
formatting changes by applying a hanging indent to table <entry>
contents if the entry is marked with role="functableentry". It may
well be possible to do this in a cleaner fashion, but this seems
good enough for discussion.

I changed table 9.30 (Date/Time Operators) to this style, doing it
exactly the same way as functions, just to see what it'd look like.
I'm not sure if this is OK or if we want a separate column with
just the operator name at the left --- it seems a little bit hard
to spot the operator you want, but not impossible. Thoughts?

Attached are screenshots of the same segment of table 9.10 as before
and of the initial portion of 9.30, the patch against HEAD to produce
these, and a hacky patch on the website's main.css to get it to go
along. Without the last you just get all the subsidiary stuff
left-justified if you build with STYLE=website, which isn't impossibly
unreadable but it's not the desired presentation.

I didn't include any screenshots of the PDF rendering, but it looks
fine.

regards, tom lane

Attachment Content-Type Size
table-9.10-v3.png image/png 390.2 KB
table-9.30-v3.png image/png 229.7 KB
doc-format-v3.patch text/x-diff 70.7 KB
website-customization.patch text/x-diff 490 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-04-17 00:27:27 Re: Problem with logical replication (crash with REPLICA IDENTITY FULL and cascading replication)
Previous Message Ranier Vilela 2020-04-16 23:54:32 [PATCH] Fix possible overflow on tuplesort.c