Re: Poll: are people okay with function/operator table redesign?
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Steven Pousty <steve.pousty@gmail.com>,
Pavel Stehule <pavel.stehule@gmail.com>,
Isaac Morland <isaac.morland@gmail.com>,
Pierre Giraud <pierre.giraud@dalibo.com>,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-04-19T10:46:32Z
Lists: pgsql-hackers
On 2020-04-17 02:25, Tom Lane wrote:
> 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.
This scares me in terms of maintainability of both the toolchain and the
markup. Table formatting is already incredibly fragile, and here we
just keep poking it until it looks a certain way instead of thinking
about semantic markup.
A good old definition list of the kind
synopsis
explanation
example or two
would be much easier to maintain on all fronts. And we could for
example link directly to a function, which is currently not really possible.
If we want to draw a box around this and change the spacing, we can do
that with CSS.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Doc: re-re-revise markup for tables of functions.
- 4ad047a6eac3 13.0 landed
-
Doc: revise formatting of function/operator tables.
- 737d69ffc3cf 13.0 landed