information_schema.tables table broken in versions 13+
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/infoschema-tables.html Description: The table on information_schema.tables documentation page is broken after version 12. Instead of three columns in header and body all text is packed inside one.
Opclass name
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/spgist-builtin-opclasses.html Description: In commit 7a1cd526 (doc: Rework tables for built-in operator classes of index AMs) the name of the inet_ops opclass was changed to network_ops. It doesn't look right, because network_ops is the name of opfamily, not opclass.
Update documentation page for translators
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/nls-translator.html Description: In the documentation for translators (https://www.postgresql.org/docs/11/nls-translator.html) it is mentioned to use any text editor for translating .po files. It can be very error prone with regular text editors, especiially for non-tech people such as translators. I thought you it would be useful to suggest usage of dedicated editors for .po files, such as "Free PO editor" (https://pofile.net/free-po-editor) which will guide them how to translate, without file structure errors.
Re: documentation describing the range of a number type 'integer' is incorrect
The bugs team agreed that it's a bug. The documentation accurately represents the buggy code. I thought you might want to update the doc when the bug is fixed. On 10/22/21 6:43 AM, Alvaro Herrera wrote: On 2021-Jul-29, PG Doc comments form wrote: https://www.postgresql.org/docs/13/datatype-numeric.html says that the range of a numeric type integer is -2147483648 to +2147483647 but PGTYPESnumeric_to_int considers -2147483648 (a perfectly valid 32-bit integer) to be invalid because it compares to -INT_MAX instead of INT_MIN or (-INT_MAX - 1). This goes back to the initial commit in the git repo for src/interfaces/ecpg/pgtypeslib/numeric.c. And doc/src/sgml/ecpg.sgml documents the min being -INT_MAX. This sounds like an ECPG bug, not a documentation problem.
Re: information_schema.tables table broken in versions 13+
PG Doc comments form writes: > The table on information_schema.tables documentation page is broken after > version 12. > Instead of three columns in header and body all text is packed inside one. That's an intentional change. regards, tom lane
Re: Opclass name
PG Doc comments form writes: > In commit 7a1cd526 (doc: Rework tables for built-in operator classes of > index AMs) the name of the inet_ops opclass was changed to network_ops. It > doesn't look right, because network_ops is the name of opfamily, not > opclass. Hm, yeah. The table title says "opclass", and that's definitely the name that would be more useful to most users, so we should list opclass not opfamily names. There are some other cases of opfname != opcname in gist and brin, but those tables seem to give the opclass name in each such case, so it's just this one mistake. regards, tom lane
nicer examples for aggregate calls
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/tutorial-agg.html Description: currently, all of the examples are very simple, like SELECT city, max(temp_lo) FROM weather WHERE city LIKE 'S%'-- (1) GROUP BY city HAVING max(temp_lo) < 40; this example would be more complex and would allow users to search for clause "filter": Finally, if we only care about cities whose names begin with “S” and we want to calculate the number of observations in each city with temp_lo over 30, we might do: SELECT city, max(temp_lo), count(*) filter (temp_lo>30), FROM weather WHERE city LIKE 'S%'-- (1) GROUP BY city HAVING max(temp_lo) < 40;
