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

Hi all,

Sorry I'm very new on this discussion. A colleague of mine told me I
could probably give my opinion on this thread.

I'm sorry in advance if I'm off topic. I just wanted to mention that
from Tom's proposal I played a bit with the generated HTML in order to
try to make things easier to read without thinking about technical
issues for now.

The first big issue (that may have already been mentioned) in my opinion
is that different elements are difficult to distinguish. It's difficult
for example to know what is the return type, what is the description, etc.

I think that if the idea is to get rid of the columns, you need to make
sure that it's easy to know which is which. With a very short amount of
time, the user should be able to find what he's looking for.

The best way to achieve this is to use some styling (font style and color).

Attached you will find two different options I worked on very quickly.

I would be happy to give more hints on how I did this of course and why
I chose some options. Please let me know.

Kind regards,

Le 13/04/2020 à 19:13, Tom Lane a écrit :
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
> https://www.postgresql.org/docs/devel/functions-datetime.html
>
> and table 9.33 at
>
> https://www.postgresql.org/docs/devel/functions-enum.html
>
> Before I spend more time on this, I want to make sure that people
> are happy with this line of attack. Comparing these tables to
> the way they look in v12, they clearly take more vertical space;
> but at least to my eye they're less cluttered and more readable.
> They definitely scale a lot better for cases where a long function
> description is needed, or where we'd like to have more than one
> example. Does anyone prefer the old way, or have a better idea?
>
> I know that the table headings are a bit weirdly laid out; hopefully
> that can be resolved [2].
>
> regards, tom lane
>
> [1] https://www.postgresql.org/message-id/flat/9326.1581457869%40sss.pgh.pa.us
> [2] https://www.postgresql.org/message-id/6169.1586794603%40sss.pgh.pa.us
>
>