Re: Documentation: 21.5. Default Roles
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 someone who controls all the moving > >>> parts, like redirects and Stephen's patch additions take ownership of > >>> this issue, with authority to revert the patch if things are too close? > > >> Magnus and I briefly discussed what it would take, but the probability > >> of having the redirects ready on pgweb before the release is > >> slim-to-none, as we'd like to thoroughly test. > > > Given the discussion, barring objections, I'll revert the changes > > tomorrow and then work with Jonathan and Magnus to try and get the > > website redirect stuff working so that we can make this change in a > > future release. > > It's Sunday afternoon, and nothing has happened, so I took it on > myself to revert this. Ah, thanks, Friday got away from me and it’s been a busy weekend, I had figured on tonight but glad you took care of it. Thanks again, Stephen >
Re: Documentation: 21.5. Default Roles
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 Stephen's patch additions take ownership of >>> this issue, with authority to revert the patch if things are too close? >> Magnus and I briefly discussed what it would take, but the probability >> of having the redirects ready on pgweb before the release is >> slim-to-none, as we'd like to thoroughly test. > Given the discussion, barring objections, I'll revert the changes > tomorrow and then work with Jonathan and Magnus to try and get the > website redirect stuff working so that we can make this change in a > future release. It's Sunday afternoon, and nothing has happened, so I took it on myself to revert this. regards, tom lane
Re: 9.4. String Functions and Operators page does not document that encode adds line breaks
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 requirement for line breaks has not > been removed by any later RFC. So you're complaining to the wrong > people. > Stating direct RFC4648 compliance would require us to drop the line breaks that are only being added due to using MIME rules which ideally our general encoding function would not do. Greenfield we probably would want base64 to be general RFC4648 and add something like base64-mime which performs the line breaking for the user per RFC 2045, base64-pem which would use that specific environments RFC rules. Now, maybe we can add "base64-4648" or "base64-general" while leaving "base64" alone and using the MIME version of the rules? David J.
Re: Lack of detailed documentation
"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.0,0)' >> I see how it can be scaling (or shearing), but how does it do rotation? >> Or maybe when the points x^2+y^2 == 1, it's interpreted at rotation? > Google: "box point multiplication postgres" came up with the follow book > section: > Haven't independently confirm the math but it sounds reasonable... I responded to the OP about this but unaccountably forgot to cc the list. The two main points were: * Per high-school-level vector geometry, rotation around the origin by an angle theta is equivalent to multiplying by the vector (cos(theta), sin(theta)). (So no, the book section you quoted isn't quite right :-(.) But we can't go and offer a geometry course on this page. * While this works for rotating points, paths, and circles, it doesn't really work for rotating boxes, because for any rotation angle that's not a multiple of 90 degrees, you'd need to end up with a tilted box ... and our box type has no notion of tilted. The specified corners rotate to the right places, but the box size isn't preserved. So it seems fairly unfortunate to me that the two examples of scaling/rotation use a box as the LHS. I could get behind changing them to use, say, a path as LHS. But I don't think there's room to explain how to do rotation if you don't know that already, any more than (say) our explanation of aggregate functions tries to explain statistics. regards, tom lane
Re: 9.4. String Functions and Operators page does not document that encode adds line breaks
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 was done a few weeks ago in HEAD: https://www.postgresql.org/docs/devel/functions-binarystring.html The base64 format is that of RFC 2045 Section 6.8. As per the RFC, encoded lines are broken at 76 characters. However instead of the MIME CRLF end-of-line marker, only a newline is used for end-of-line. The decode function ignores carriage-return, newline, space, and tab characters. Otherwise, an error is raised when decode is supplied invalid base64 data — including when trailing padding is incorrect. > By the way, this is a very poor design decision. So far as I can tell, that RFC's requirement for line breaks has not been removed by any later RFC. So you're complaining to the wrong people. regards, tom lane
