Re: Getting our tables to render better in PDF output

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Yeah, it'd look very odd, and certainly the no-parens case makes it
> worse. I like this end result:

>> Function Signature
>> age age(timestamp) → interval
>> now now() → timestamp with time zone
>> current_timestamp current_timestamp → timestamp with time zone

I gave that a try, and it seems to work really well. It can even handle
the ridiculously long signature for make_interval() in reasonable style,
as shown in the screenshot attached.

One problem with the rightarrow idea is that it's not rendering quite
right for me: it looks great in HTML, but in PDF it comes out flush
with the baseline, as you can see in the screenshot. Hopefully
there's a way to fix that that we can hide in the custom entity ...
but I have no idea how.

I decided to try converting the date/time operators table too, to
see how well this works for that. It's bulkier than before, but
also (I think) more precise. I realized that this table actually
had three examples already for float8 * interval, but it wasn't
at all obvious that they were the same operator. So that aspect
is a lot nicer here. On the other hand, it seems like the text
descriptions are only marginally useful here. I can imagine that
they would be useful in some other operator tables, such as
geometric operators, but I'm a bit tempted to leave them out
in this particular table. The format would adapt to that easily.

Another thing worth considering is removing duplicate left-hand-
column entries, that is, considering all the instances of
similarly-named functions/operators to be "the same". In the
attached patch, I did that for isfinite() but not anywhere else.
I'm not quite sure if it's a good idea or not. It seems like it
makes sense for isfinite(), but perhaps less so for operators.

Again, comments welcome. This is starting to feel like a real
proposal now, but I'm still not at all wedded to it.

regards, tom lane