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 18929.1586811439@sss.pgh.pa.us
Whole thread Raw
In response to Re: Poll: are people okay with function/operator table redesign?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Poll: are people okay with function/operator table redesign?  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
I wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> I don't think having a separate Result column helps.  The additional
>> horizontal whitespace distances all relevant context information (at least
>> on a wide monitor).  Having the example rows mirror the Signature row seems
>> like an easier to consume choice.

> Interesting idea.  I'm afraid that it would not look so great in cases
> where the example-plus-result overflows one line, which would inevitably
> happen in PDF format.  Still, maybe that would be rare enough to not be
> a huge problem.  In most places it'd be a win to not have to separately
> allocate example and result space.

Actually ... if we did it like that, then it would be possible to treat
the signature + description + example(s) as one big table cell with line
breaks rather than row-separator bars.  That would help address the
inadequate-visual-separation-between-groups issue, but on the other hand
maybe we'd end up with too little visual separation between the elements
of a function description.

A quick google search turned up this suggestion about how to force
line breaks in docbook table cells:

http://www.sagehill.net/docbookxsl/LineBreaks.html

which seems pretty hacky but it should work.  Anyone know a better
way?

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: documenting the backup manifest file format
Next
From: "David G. Johnston"
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?