Greetings,
On Sun, Feb 9, 2020 at 14:24 Tom Lane wrote:
> Stephen Frost writes:
> > * Jonathan S. Katz (jk...@postgresql.org) wrote:
> >> On 2/6/20 12:11 AM, Bruce Momjian wrote:
> >>> Folks, is it Thursday. Can we revert this and return to it when we are
> >>> not rushed? Alternatively, can
Stephen Frost writes:
> * Jonathan S. Katz (jk...@postgresql.org) wrote:
>> On 2/6/20 12:11 AM, Bruce Momjian wrote:
>>> Folks, is it Thursday. Can we revert this and return to it when we are
>>> not rushed? Alternatively, can someone who controls all the moving
>>> parts, like redirects and St
On Sun, Feb 9, 2020 at 9:03 AM Tom Lane wrote:
> PG Doc comments form writes:
>
> The base64 format is that of RFC 2045 Section 6.8. As per the RFC,
> encoded lines are broken at 76 characters
>
> > By the way, this is a very poor design decision.
>
> So far as I can tell, that RFC's requireme
"David G. Johnston" writes:
> On Fri, Feb 7, 2020 at 4:53 PM PG Doc comments form
> wrote:
>> On: https://www.postgresql.org/docs/current/functions-geometry.html
>> The functions aren't defined, nor have pointers. For instance:
>> * Scaling/rotationbox '((0,0),(1,1))' * point '(2.
PG Doc comments form writes:
> It took me a long time to discover why a base 64 encoded SHA-512 hash was 89
> characters long instead of the expected 88. The documentation does not
> mention that the encode function inserts newlines after 76 characters.
> Please make a note of this behavior.
That
