Re: Poll: are people okay with function/operator table redesign? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Poll: are people okay with function/operator table redesign?
Date
Msg-id 20662.1587048193@sss.pgh.pa.us
Whole thread Raw
In response to Re: Poll: are people okay with function/operator table redesign?  (Pierre Giraud <pierre.giraud@dalibo.com>)
Responses Re: Poll: are people okay with function/operator table redesign?
List pgsql-hackers
Pierre Giraud <pierre.giraud@dalibo.com> writes:
> Le 16/04/2020 à 00:18, Tom Lane a écrit :
>> The main disadvantage I can see to the v2 design is that we're back
>> to having two <rows> per function, which is inevitably going to result
>> in PDF builds putting page breaks between those rows.  But you can't
>> have everything ... and maybe we could find a way to discourage such
>> breaks if we tried.

Further experimentation shows that the PDF toolchain is perfectly willing
to put a page break *within* a multi-line <row>; if there is any
preference to break between rows instead, it's pretty weak.  So that
argument is a red herring and we shouldn't waste time chasing it.
However, there'd still be some advantage in not being dependent on CSS
hackery to make it look nice in HTML.

What we're down to wanting, at this point, is basically a para with
hanging indent.

> What about putting everything into one <table row> and use a block with
> some left padding/margin for description + example.
> This would solve the PDF page break issue as well as the column
> separation border one.
> The screenshot attached uses a <dl> tag for the descrition/example block.

That looks about right, perhaps, but could you be a little clearer about
how you accomplished that?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: cleaning perl code
Next
From: Tom Lane
Date:
Subject: Re: remove_useless_groupby_columns does not need to record constraint dependencies