Re: Typo on tutorial window page

sorry, my bad, thanks for the clarification! вт, 21 січ. 2025 р., 18:40 користувач David G. Johnston < david.g.johns...@gmail.com> пише: > On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote: > >> PG Doc comments form writes: >> > EXPECTED: >> > As shown here, the rank function produces a numerical

Re: Typo on tutorial window page

"David G. Johnston" writes: > I was going to write basically that but something feels off to me. Maybe > something like this: > "As shown here, the rank function produces a numerical ranking within each > partition, using the order defined by the ORDER BY clause. Ranking assigns > the same rank

Re: Typo on tutorial window page

On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote: > PG Doc comments form writes: > > EXPECTED: > > As shown here, the rank function produces a numerical rank for each > distinct > > PARTITION BY value in the current row's partition, using the order > defined > > by the ORDER BY clause. rank needs

Re: Typo on tutorial window page

On Tue, Jan 21, 2025 at 10:39 AM Tom Lane wrote: > PG Doc comments form writes: > > EXPECTED: > > As shown here, the rank function produces a numerical rank for each > distinct > > PARTITION BY value in the current row's partition, using the order > defined > > by the ORDER BY clause. rank needs

Re: Typo on tutorial window page

PG Doc comments form writes: > EXPECTED: > As shown here, the rank function produces a numerical rank for each distinct > PARTITION BY value in the current row's partition, using the order defined > by the ORDER BY clause. rank needs no explicit parameter, because its > behavior is entirely determ

Typo on tutorial window page

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/tutorial-window.html Description: EXPECTED: As shown here, the rank function produces a numerical rank for each distinct PARTITION BY value in the current row's partition, using the order

Re: Typo in doc page?

umentation page: > https://www.postgresql.org/docs/current/sql-keywords-appendix.html > there seems to be a typo where keyword END_EXEC is mistyped as END-EXEC. > I am not myself familiar with this keyword but, if not a typo, this would > make it the only hyphenated keyword and, therefore,

Typo in doc page?

a typo where keyword END_EXEC is mistyped as END-EXEC. I am not myself familiar with this keyword but, if not a typo, this would make it the only hyphenated keyword and, therefore, a note should probably be added to the entry stating that it is correctly spelled. Thanks!

Re: Typo on 2.3. PostgreSQL

PG Doc comments form writes: > In https://www.postgresql.org/docs/16/history.html#HISTORY-POSTGRESQL, > Chapter 2.3. PostgreSQL is written in first sentence: "By 1996, it became > clear that the name “Postgres95” would not stand the test of time." > I think there should be "the rest of time" inste

Typo on 2.3. PostgreSQL

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/history.html Description: In https://www.postgresql.org/docs/16/history.html#HISTORY-POSTGRESQL, Chapter 2.3. PostgreSQL is written in first sentence: "By 1996, it became clear that the na

Re: Typo in 15.3.4

the website: >> >> Page: https://www.postgresql.org/docs/16/parallel-plans.html >> Description: >> >> In section 15.3.4, I believe "multiple results sets" is a typo for >> "multiple >> result sets". It says: >> >> > Plans

Re: Typo in 15.3.4

15.3.4, I believe "multiple results sets" is a typo for "multiple result sets". It says: > Plans that involve appending multiple results sets can therefore achieve coarse-grained parallelism even when efficient partial plans are not available. It's also possible this sh

Re: Typo in 15.3.4

On Thu, Jul 25, 2024 at 9:50 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/parallel-plans.html > Description: > > In section 15.3.4, I believe "multiple results sets&quo

Typo in 15.3.4

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/parallel-plans.html Description: In section 15.3.4, I believe "multiple results sets" is a typo for "multiple result sets". It says: > Plans that involve appendin

Re: A typo?

On Sun, Apr 7, 2024 at 7:24 AM jian he wrote: > On Sun, Apr 7, 2024 at 6:30 PM PG Doc comments form > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html > > Description: > > > > Under 43.3.

Re: A typo?

"David G. Johnston" writes: > On Saturday, April 6, 2024, PG Doc comments form > wrote: >> Under 43.3.1, "Notice that we omitted RETURNS real — we could have included >> it, but it would be redundant." >> Should that be "RETURNS tax" instead of "RETURNS real"? > The docs are correct. Specifical

Re: A typo?

On Sun, Apr 7, 2024 at 6:30 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html > Description: > > Under 43.3.1, "Notice that we omitted RETURNS real — we could have included >

Re: A typo?

On Saturday, April 6, 2024, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html > Description: > > Under 43.3.1, "Notice that we omitted RETURNS real — we could have included > it,

A typo?

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/plpgsql-declarations.html Description: Under 43.3.1, "Notice that we omitted RETURNS real — we could have included it, but it would be redundant." Should that be "RETURNS tax" instead of "

Re: Minor typo in Section, 27.2.8.4.

On Fri, Mar 8, 2024 at 09:15:35PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/warm-standby.html > Description: > > Section, 27.2.8.4. Planning For High Availability is missing the word "the"

Minor typo in Section, 27.2.8.4.

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/warm-standby.html Description: Section, 27.2.8.4. Planning For High Availability is missing the word "the" as shown below .. "Such transaction commits may never be completed if any one of

Re: Typo in '8.5. Date/Time Types' v16

PG Doc comments form writes: > In the interval example outputs, for postgres and postgres_verbose. > It says mons instead of months. That is in fact the datatype's output format. regression=# show intervalstyle; IntervalStyle --- postgres (1 row) regression=# select '2 month'::in

Typo in '8.5. Date/Time Types' v16

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/datatype-datetime.html Description: Hello, In the interval example outputs, for postgres and postgres_verbose. It says mons instead of months.

Re: Typo in documentation - runtime-config-wal

On Fri, Feb 15, 2019 at 07:51:31PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/runtime-config-wal.html > Description: > > This page: https://www.postgresql.org/docs/10/runtime-config-wal.html

Re: Typo in "43.9.1. Reporting Errors and Messages"?

On Wed, Nov 01, 2023 at 09:18:47AM +0900, Michael Paquier wrote: > So you mean something like the attached then? Fixed that with f8b96c211da0 down to 11, in time for next week's release set. -- Michael signature.asc Description: PGP signature

Re: Typo in "43.9.1. Reporting Errors and Messages"?

On Tue, Oct 31, 2023 at 09:00:00PM +0300, Alexander Lakhin wrote: > I don't remember details, but I think the primary reason for the change > was that "RAISE_EXCEPTION" occurred in the whole tree only once (before > 66bde49d96). Now I see, that I had chosen the wrong replacement — I agree > with Eu

Re: Typo in "43.9.1. Reporting Errors and Messages"?

Hi Bruce, 31.10.2023 17:52, Bruce Momjian wrote: It is referring to the internal constant (see src/backend/utils/errcodes.h). It was like you are proposing and it was changed in 66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5. Reading the original thread, there is no explanation why it was changed. R

Re: Typo in "43.9.1. Reporting Errors and Messages"?

king at the list of error codes (here > https://www.postgresql.org/docs/current/errcodes-appendix.html) I think > the > "ERRCODE_RAISE_EXCEPTION (P0001)" is a typo and should remove "ERRCODE_" > and > simply read "RAISE_EXCEPTION (P0001)" or perhaps "

Re: Typo in docs for "recovery_init_sync_method" parameter.

On Tue, Aug 23, 2022 at 02:38:13PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/runtime-config-error-handling.html > Description: > > The second paragraph contains the sentence: > > > ...

Re: Typo in PL/pgSQL trigger Example 43.4?

Daniel Gustafsson writes: >> On 7 Oct 2023, at 22:22, Tom Lane wrote: >> Yeah, either way has the same result. However, I wonder if we should >> change this example to use current_user for clarity. It does look >> more like it's intended to be a variable or column reference than >> a built-in f

Re: Typo in PL/pgSQL trigger Example 43.4?

> On 7 Oct 2023, at 22:22, Tom Lane wrote: > > "David G. Johnston" writes: >> On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote: >>> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN >>> QUESTION >>> The emp_audit table has a column named 'userid', which in actual usage >

Re: Typo in PL/pgSQL trigger Example 43.4?

On Sat, Oct 7, 2023 at 1:22 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote: > >> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN > QUESTION > >> The emp_audit table has a column named 'userid', which in actual usage

Re: Typo in PL/pgSQL trigger Example 43.4?

"David G. Johnston" writes: > On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote: >> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN >> QUESTION >> The emp_audit table has a column named 'userid', which in actual usage >> (next-to-last line quoted) is populated by 'user' w

Re: Typo in PL/pgSQL trigger Example 43.4?

On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote: > > INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= > ARGUMENT IN QUESTION > The emp_audit table has a column named 'userid', which in actual usage > (next-to-last line quoted) is populated by 'user' which seems undefined

Typo in PL/pgSQL trigger Example 43.4?

The PL/pgSQL page on triggers ( https://www.postgresql.org/docs/16/plpgsql-trigger.html ) contains the following example (I'm excerpting only the essential parts here): Example 43.4. A PL/pgSQL Trigger Function for Auditing ... CREATE TABLE emp_audit( operation char(1) NOT NULL

Re: Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

Daniel Gustafsson writes: >> On 22 Sep 2023, at 19:04, Tom Lane wrote: >> I propose the attached. (I also modified the para's last sentence to >> speak of "kind" not "type", for consistency with the relkind field name >> and the rest of the para.) > LGTM. Pushed, thanks for looking.

Re: Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

> On 22 Sep 2023, at 19:04, Tom Lane wrote: > > I wrote: >> "Most" here is good English, although I concede it's a slightly >> old-fashioned usage. Maybe it'd be clearer to just remove the >> word altogether. > >> If we were going to touch this sentence I'd worry about some other >> things too.

Re: Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

I wrote: > "Most" here is good English, although I concede it's a slightly > old-fashioned usage. Maybe it'd be clearer to just remove the > word altogether. > If we were going to touch this sentence I'd worry about some other > things too. Use of "catalogs" as a verb is probably not the greates

Re: Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

Daniel Gustafsson writes: >> On 20 Sep 2023, at 07:23, PG Doc comments form >> wrote: >> I've just read this: >> "catalogs tables and most everything else that has columns or is otherwise >> similar to a table" >> It seems that it should be: >> "catalogs tables and almost everything else that ha

Re: Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

> On 20 Sep 2023, at 07:23, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/catalog-pg-class.html > Description: > > I've just read this: > > "catalogs tables and most everything else that has colu

Typo/wording on https://www.postgresql.org/docs/current/catalog-pg-class.html

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/catalog-pg-class.html Description: I've just read this: "catalogs tables and most everything else that has columns or is otherwise similar to a table" It seems that it should be: "catal

Re: Typo

On Tuesday, May 23, 2023, Tom Lane wrote: > Laurenz Albe writes: > > On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote: > >> This is the current sentence, and it sounds kind of OK to me, FWIW: > >> "Postgres95 code was completely ANSI C and trimmed in size by 25%. > > > That uses "ANSI C"

Re: Typo

Laurenz Albe writes: > On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote: >> This is the current sentence, and it sounds kind of OK to me, FWIW: >> "Postgres95 code was completely ANSI C and trimmed in size by 25%. > That uses "ANSI C" as an adjective, which I think is sloppy wording > (ev

Re: Typo

On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote: > On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote: > > There appears to be a typo, here: > > https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%20C

Re: Typo

On Tue, May 23, 2023 at 3:32 PM Michael Paquier wrote: > On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote: > > There appears to be a typo, here: > > > https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%

Re: Typo

On Tue, May 23, 2023 at 08:52:25PM +, PG Doc comments form wrote: > There appears to be a typo, here: > https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20ANSI%20C. > A word or two should be added between 'completely' and 

Typo

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/history.html Description: Hi Folks, thank you for maintaining this great technical resource, which I've only recently started to use. There appears to be a typo, here:

Re: Minor typo in 13.3.5. Advisory Locks

> On 31 Mar 2023, at 14:35, Tom Lane wrote: > > Daniel Gustafsson writes: >> Reading this section I agree that the mix of ok/danger in the same example >> can >> be tad misleading though. Something like the attached is what I would prefer >> as a reader. > > I think in your rewrite, "this que

Re: Minor typo in 13.3.5. Advisory Locks

Daniel Gustafsson writes: > Reading this section I agree that the mix of ok/danger in the same example can > be tad misleading though. Something like the attached is what I would prefer > as a reader. I think in your rewrite, "this query" is dangling a bit because there's several sentences more

Re: Minor typo in 13.3.5. Advisory Locks

> On 28 Mar 2023, at 22:45, Tom Lane wrote: > > PG Doc comments form writes: >> Page: https://www.postgresql.org/docs/15/explicit-locking.html > >> After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks >> (https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LO

Re: Minor typo in 13.3.5. Advisory Locks

PG Doc comments form writes: > Page: https://www.postgresql.org/docs/15/explicit-locking.html > After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks > (https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS) > I believe there is a mistake in this sentence (I

Minor typo in 13.3.5. Advisory Locks

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/explicit-locking.html Description: After the code snippet in the 6th paragraph of 13.3.5. Advisory Locks (https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS) I be

Re: meson doc: Is "-Dtap-tests" a typo?

On 2023-02-15 13:44, Michael Paquier wrote: On Tue, Feb 14, 2023 at 09:06:13AM +, Katsuragi Yuta wrote: The parameter name "-Dtap-tests" in the meson's doc seems to be a typo. I think "-Dtap_tests" is the correct name. Attached patch fixes that. I got an unkno

Re: meson doc: Is "-Dtap-tests" a typo?

On Tue, Feb 14, 2023 at 09:06:13AM +, Katsuragi Yuta wrote: > The parameter name "-Dtap-tests" in the meson's doc seems to be a typo. > I think "-Dtap_tests" is the correct name. Attached patch fixes that. > > I got an unknown options error by

meson doc: Is "-Dtap-tests" a typo?

Hi, The parameter name "-Dtap-tests" in the meson's doc seems to be a typo. I think "-Dtap_tests" is the correct name. Attached patch fixes that. I got an unknown options error by using "-Dtap-tests=enabled". However, meson_options.txt told me the corre

Re: Typo in 2.7 Aggregate Functions

PG Doc comments form writes: > Near the end of Chapter 2.7 Aggregate Functions of the documentation, the > command FILTER is introduced. The full query is > SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30) > FROM weather > GROUP BY city > HAVING max(temp_lo) < 40; > an

Typo in 2.7 Aggregate Functions

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/tutorial-agg.html Description: Near the end of Chapter 2.7 Aggregate Functions of the documentation, the command FILTER is introduced. The full query is SELECT city, max(temp_lo), count(*

Re: Minor typo in sentence saving visits to heap

PG Doc comments form writes: > In the documentation on > https://www.postgresql.org/account/comments/new/15/indexes-multicolumn.html/ > Constraints on columns to the right of these columns are checked in the > index, so they save visits to the table proper, but they do not reduce the > portion of

Minor typo in sentence saving visits to heap

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/indexes-multicolumn.html Description: In the documentation on https://www.postgresql.org/account/comments/new/15/indexes-multicolumn.html/ ``` Constraints on columns to the right of these

Typo in docs for "recovery_init_sync_method" parameter.

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/runtime-config-error-handling.html Description: The second paragraph contains the sentence: > ...to ask the operating system to synchronize the whole file systems that contain the dat

Re: Typo in description of PROGRAM parameter for the COPY command

Daniel Gustafsson writes: > Skimming the page I noticed that we wrap CSV in in all but a few > places, which seemed randomly "chosen". Another sentence which stood out to > me > was this one on FREEZE: > "This violates the normal rules of MVCC visibility and users specifying > shou

Re: Typo in description of PROGRAM parameter for the COPY command

> On 21 Aug 2022, at 20:48, Tom Lane wrote: > > Daniel Gustafsson writes: >> On 21 Aug 2022, at 03:31, PG Doc comments form >> wrote: >>> ...so if you need to pass any arguments to shell command that come >>> from an untrusted source... >>> >>> The "to shell command that come" part should be

Re: Typo in description of PROGRAM parameter for the COPY command

Daniel Gustafsson writes: > On 21 Aug 2022, at 03:31, PG Doc comments form wrote: >> ...so if you need to pass any arguments to shell command that come >> from an untrusted source... >> >> The "to shell command that come" part should be changed so it either reads >> like this: >> >> ...so if yo

Re: Typo in description of PROGRAM parameter for the COPY command

> On 21 Aug 2022, at 03:31, PG Doc comments form wrote: >> ...so if you need to pass any arguments to shell command that come > from an untrusted source... > > The "to shell command that come" part should be changed so it either reads > like this: > >> ...so if you need to pass any arguments to

Typo in description of PROGRAM parameter for the COPY command

a minor typo: > ...so if you need to pass any arguments to shell command that come from an untrusted source... The "to shell command that come" part should be changed so it either reads like this: > ...so if you need to pass any arguments to a shell command that comes f

Re: Typo in "43.9.1. Reporting Errors and Messages"?

; > > If no condition name nor SQLSTATE is specified in a RAISE EXCEPTION > command, the default is to use ERRCODE_RAISE_EXCEPTION (P0001). > > Looking at the list of error codes (here > https://www.postgresql.org/docs/current/errcodes-appendix.html) I think the > "ERRCO

Typo in "43.9.1. Reporting Errors and Messages"?

rent/errcodes-appendix.html) I think the "ERRCODE_RAISE_EXCEPTION (P0001)" is a typo and should remove "ERRCODE_" and simply read "RAISE_EXCEPTION (P0001)" or perhaps "ERRCODE = 'RAISE_EXCEPTION'" since that's how the default behaviour would be written in a RAISE statement. Many thanks, Eric Mutta.

Re: Typo in examples in "8.14.5. jsonb Subscripting"

On Thu, Jul 07, 2022 at 12:27:01AM +, PG Doc comments form wrote: > Towards the end of the section, the code examples given have comments where > the JSON is using single quotes instead of double quotes around the > properties. For example this: > > -- Where jsonb_field was {}, it is now {

Typo in examples in "8.14.5. jsonb Subscripting"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/datatype-json.html Description: Towards the end of the section, the code examples given have comments where the JSON is using single quotes instead of double quotes around the properties.

Re: documentation typo

> On 31 Jan 2022, at 23:05, Tom Lane wrote: > It's hard to explain why lo_creat is there at all without mentioning > 8.1, so I ended up with the below, which basically says that lo_creat > is only useful for talking to pre-8.1 servers. Agreed, makes sense. > Comments? LGTM. -- Daniel Gustaf

Re: documentation typo

Daniel Gustafsson writes: >> On 30 Jan 2022, at 16:52, Tom Lane wrote: >> I could get behind documenting the more modern >> one first, though. > +1 Proposed patch attached. >> I wonder if it's time to remove the references to PG 8.1? > I think it's time to remove references to 8.0 and 8.1 to

Re: documentation typo

> On 30 Jan 2022, at 16:52, Tom Lane wrote: > I could get behind documenting the more modern > one first, though. +1 > I wonder if it's time to remove the references to PG 8.1? I think it's time to remove references to 8.0 and 8.1 to de-clutter the page, 8.3 or 8.4 seems like a better lower li

Re: documentation typo

Magnus Hagander writes: > It might be worth splitting that part into one section with the > current function (lo_create) and then a separate section with the > backwards-compatible lo_creat function though -- I can see how it's > easy to come to the conclusion you did from reading it, and that cou

Re: documentation typo

On Sun, Jan 30, 2022 at 1:39 PM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/lo-interfaces.html > Description: > > I assume "inv_oid = lo_creat(conn, INV_READ|INV_WRITE);" should be "inv_oid > = lo_

documentation typo

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/lo-interfaces.html Description: I assume "inv_oid = lo_creat(conn, INV_READ|INV_WRITE);" should be "inv_oid = lo_create(conn, INV_READ|INV_WRITE);", right? https://www.postgresql.org/docs/

Re: Typo in "27.2.8. Synchronous Replication"

docs - they really make a difference to those of us coming from other (commerical) databases! On Wed, Jan 19, 2022, 02:28 David G. Johnston wrote: > On Tue, Jan 18, 2022 at 4:01 PM Eric Mutta wrote: > >> >> 2. I noticed the typo and on the top right of the page there's an &q

Re: Typo in "27.2.8. Synchronous Replication"

On Tue, Jan 18, 2022 at 4:01 PM Eric Mutta wrote: > > 2. I noticed the typo and on the top right of the page there's an "edit" > link. Click that and it takes you to GitHub where the Markdown text is. > I suspect a large part of your expectation is based upon this

Re: Typo in "27.2.8. Synchronous Replication"

a few clicks from start to finish. Here's the flow from a real example: 1. There was a typo in the "Restore and Recovery Overview (SQL Server)" docs here https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server?view=sql-ser

Re: Typo in "27.2.8. Synchronous Replication"

wondering is there anything similar for the Postgres docs? > > Going through a mailing list just to fix a typo feels like a lot of overhead! Hi! Personally, I would find sending an email to a mailing list or like you did, filling out the form on the website, would be *less* overhead than hav

Re: Typo in "27.2.8. Synchronous Replication"

t; wondering is there anything similar for the Postgres docs? > > Going through a mailing list just to fix a typo feels like a lot of overhead! No, sorry, there is not an easier way. -- Bruce Momjian https://momjian.us EDB https://enterprise

Re: Typo in "27.2.8. Synchronous Replication"

list just to fix a typo feels like a lot of overhead! On Sun, Jan 2, 2022, 19:08 Magnus Hagander wrote: > On Mon, Dec 27, 2021 at 12:07 AM PG Doc comments form > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://w

Re: Typo in "27.2.8. Synchronous Replication"

On Mon, Dec 27, 2021 at 12:07 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/warm-standby.html > Description: > > The following sentence: > > > The minimum wait time is the round-trip time **betwee

Typo in "27.2.8. Synchronous Replication"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/warm-standby.html Description: The following sentence: > The minimum wait time is the round-trip time **between primary to standby.** Should either end with "...between primary AND stand

Re: Typo in release notes for pg14

On Thu, 23 Sep 2021, 16:45 Tom Lane, wrote: > > No, "memoize" is the intended spelling. > > regards, tom lane Oh, my bad. Cool new term. Thanks.

Re: Typo in release notes for pg14

Erwin Brandstetter writes: > https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7 >> Add executor method to memoize results from the inner side of a > nested-loop join (David Rowley) > -> > Add executor method to memorize results from the inner side of a > nested-loop join (David

Re: Typo in release notes for pg14

> On 23 Sep 2021, at 16:26, Erwin Brandstetter wrote: > > https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7 > > > Add executor method to memoize results from the inner side of a nested-loop > > join (David Rowley) > > -> > Add executor method to memorize results from the inn

Typo in release notes for pg14

https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.5.5.3.7 > Add executor method to memoize results from the inner side of a nested-loop join (David Rowley) -> Add executor method to memorize results from the inner side of a nested-loop join (David Rowley) Regards Erwin

Re: Typo in "13.2.3. Serializable Isolation Level"

> That sentence is a suggestion of an action for the reader to take, conditionally upon verifying that such things are no longer necessary. I see, that makes sense now, I was parsing the sentence differently. Perhaps for clarity those explicit locks could be mentioned in brackets so the sentence r

Re: Typo in "13.2.3. Serializable Isolation Level"

PG Doc comments form writes: > The following sentence: >> Eliminate explicit locks, SELECT FOR UPDATE, and SELECT FOR SHARE where no > longer needed due... > Uses the word "where" when it should probably use the word "are" and thus > read: > Eliminate explicit locks, SELECT FOR UPDATE, and SELE

Typo in "13.2.3. Serializable Isolation Level"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/transaction-iso.html Description: The following sentence: > Eliminate explicit locks, SELECT FOR UPDATE, and SELECT FOR SHARE where no longer needed due... Uses the word "where" when it

RE: typo in doc for "Miscellaneous Coding Conventions"

>"were not" is typical usage when stating a contrary-to-fact hypothetical. > If the implementation (or you) didn’t do X, then Y bad thing could happen. Really thanks for your kindly reply and explain. Please forgive me for my poor English. Anyway, got it. Regards, Tang

Re: typo in doc for "Miscellaneous Coding Conventions"

t...@sss.pgh.pa.us wrote: > PG Doc comments form writes: > >> small fix in description at [1] as follows > >> -If that were not done interrupted code that's currently inspecting errno >> might see the wrong value. >> +If that was not done interrupted code that's currently inspecting errno >> mi

Re: typo in doc for "Miscellaneous Coding Conventions"

PG Doc comments form writes: > small fix in description at [1] as follows > -If that were not done interrupted code that's currently inspecting errno > might see the wrong value. > +If that was not done interrupted code that's currently inspecting errno > might see the wrong value. The existing

typo in doc for "Miscellaneous Coding Conventions"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/source-conventions.html Description: small fix in description at [1] as follows -If that were not done interrupted code that's currently inspecting errno might see the wrong value. +If th

Re: Typo in DATATYPE-JSONPATH

On Fri, Apr 16, 2021 at 08:11:53AM +0200, Erik Rijkers wrote: > FWIW, I agree with this and already sent a doc-patch [1], which is > be applied from 12, 13, and master. Arf. I completely forgot about this thread but I marked it as something to look at. Will do so now. -- Michael signature.asc

Re: Typo in DATATYPE-JSONPATH

> On 2021.04.15. 22:04 PG Doc comments form wrote: > > Page: https://www.postgresql.org/docs/13/datatype-json.html > Description: > > Hello, > > On the DATATYPE-JSONPATH page: > https://www.postgresql.org/docs/13/datatype-json.html#DATATYPE-JSONPATH > > There is a line that shows that GIN ind

Typo in DATATYPE-JSONPATH

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/datatype-json.html Description: Hello, On the DATATYPE-JSONPATH page: https://www.postgresql.org/docs/13/datatype-json.html#DATATYPE-JSONPATH There is a line that shows that GIN indexes

Re: Typo in psql doc

Yes indeed, thanks. I re-tested the example this morning and it worked correctly with the space. I guess I had messed up things when I first tried it. Michael Paquier 14 April 2021 at 07:58 Both commands sey in your .psqlrc results in the same path being used, as I

Re: Typo in psql doc

On Thu, Apr 15, 2021 at 09:55:53AM +0200, Ludovic Kuty wrote: > Yes indeed, thanks. I re-tested the example this morning and it worked > correctly with the space. I guess I had messed up things when I first tried > it. After seeing Tom's argument that this behavior become more consistent in 9.2, a

Re: Typo in psql doc

On Wed, Apr 14, 2021 at 10:12:02AM -0400, Tom Lane wrote: > As you say, both ways now give the same result. Since it's not the > point of this example to illustrate \set's space-eating behavior, > it might be clearer to revert the addition of the space. Oh, interesting point. I did not notice th

  1   2   3   >