Re: Proposed HTML Documentation Styles

2018-10-14 Thread Dean Rasheed
On Fri, 12 Oct 2018 at 03:03, Jonathan S. Katz  wrote:
> On 10/11/18 3:01 AM, Dean Rasheed wrote:
> > On Thu, 11 Oct 2018 at 06:49, Dean Rasheed  wrote:
> >> For example, attached are screenshots taken from my Android tablet
> >
> > For the record, that was a Samsung Galaxy Tab S2 8.0, with a screen
> > resolution of 2048x1536 and a device pixel ratio of 2.0, I think. So
> > the logical resolution is 1024x768, and in portrait mode, the logical
> > width is 768 pixels.
>
> Unfortunately HTML tables are not great in mobile web. With that said,
> we pushed up a change that should keep them from exploding as much to
> the right. We've also bumped up the font-size slightly from the current
> site so they could be slightly easier to read.
>
> (Note: when testing in the browser, they appear to be illegible unless
> you have super vision, but when on an actual device they are legible).
>
> There is only so much we can do now without redesigning how the tables
> are assembled.
>

Indeed. It's probably unrealistic to try to support really small
devices. I mentioned that particular one because there was a clear
regression from the old style. I have re-tested it and now it's much
better, so thanks for the fix.

Arguably, the font scaling in the @media CSS is now a little too
aggressive. IMO 60% rather than 50% is a little more readable for the
576-768px range, and 80% rather than 70% for the 769-992px range, but
that's a very subjective matter.

Regards,
Dean



bloom documentation patch

2018-10-14 Thread Oleg Bartunov
Hi,

Please, consider attached patch, which improves contrib/bloom documentation.

Best regards,
Oleg
-- 
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


bloom.sgml.patch
Description: Binary data


Re: bloom documentation patch

2018-10-14 Thread Thomas Munro
On Mon, Oct 15, 2018 at 10:15 AM Oleg Bartunov  wrote:
> Please, consider attached patch, which improves contrib/bloom documentation.

Hello Oleg, I have no comment on the technical details but here is
some proof-reading of the English:

+  Length of each signature (index entry) in bits, it is rounded
up to the nearest
+  multiple of 16. The default is 80 bits and maximum is

s/, it is/.  It is/
s/and maximum/and the maximum/

+   Bloom AM doesn't supports unique indexes.

s/supports/support/

+   Bloom AM doesn't supports NULL values.

s/supports/support/

-- 
Thomas Munro
http://www.enterprisedb.com



Re: Ambiguous usage of 'any' in explanation

2018-10-14 Thread David G. Johnston
On Saturday, October 13, 2018, Bruce Momjian  wrote:

> On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote:
> > >or NULL if any of the comparisons result in unknown
> > result in unknown??
>
> Well, SQL has a three-valued logic, and UNKOWN values are treated like
> NULL.  For me they have always been the same, and I would like to avoid
> "unknown" in this context, if possible.
>
>
I was just trying to avoid using the word null twice in the same sentence
but it’s not a strong aversion.

David J.