public inbox for [email protected]help / color / mirror / Atom feed
Typo 20+ messages / 11 participants [nested] [flat]
* Typo @ 2016-06-04 07:28 [email protected] 0 siblings, 1 reply; 20+ messages in thread From: [email protected] @ 2016-06-04 07:28 UTC (permalink / raw) To: pgsql-docs The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/static/backup-dump.html Description: Before restoring an SQL dump, Should be Before restoring a SQL dump, -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2016-06-07 02:44 Michael Paquier <[email protected]> parent: [email protected] 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2016-06-07 02:44 UTC (permalink / raw) To: [email protected]; +Cc: pgsql-docs On Sat, Jun 4, 2016 at 4:28 PM, <[email protected]> wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.5/static/backup-dump.html > Description: > > Before restoring an SQL dump, > > Should be > > Before restoring a SQL dump, The source code has a shared opinion on the matter: $ git grep "a SQL" | wc -l 630 $ git grep "an SQL" | wc -l 238 Based on some past memories of some basic English lessons, this should be "an" I think, because the S of SQL spells as "esse" :) -- Michael -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2016-06-07 02:56 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Tom Lane @ 2016-06-07 02:56 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: [email protected]; pgsql-docs Michael Paquier <[email protected]> writes: > On Sat, Jun 4, 2016 at 4:28 PM, <[email protected]> wrote: >> Before restoring an SQL dump, >> Should be >> Before restoring a SQL dump, > The source code has a shared opinion on the matter: > $ git grep "a SQL" | wc -l > 630 > $ git grep "an SQL" | wc -l > 238 > Based on some past memories of some basic English lessons, this should > be "an" I think, because the S of SQL spells as "esse" :) It depends on whether you prefer to spell out the abbreviation or pronounce it as a word. So I would read it as either "a sequel dump" or "an ess-cue-ell dump". Either is correct on its own terms, which is why there's not a very strong consensus in our code/docs. I'm not excited about trying to standardize on one vs. the other. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Typo. @ 2016-06-07 11:26 Dmitry Igrishin <[email protected]> 0 siblings, 2 replies; 20+ messages in thread From: Dmitry Igrishin @ 2016-06-07 11:26 UTC (permalink / raw) To: pgsql-docs Hi, In "Internal position: this is defined the same as the P field, but it is used when the cursor position refers to an internally generated", "internally generated" should be replaced with "internally-generated". https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html -- // Dmitry. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 12:08 Dmitry Igrishin <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 0 replies; 20+ messages in thread From: Dmitry Igrishin @ 2016-06-07 12:08 UTC (permalink / raw) To: pgsql-docs 2016-06-07 14:26 GMT+03:00 Dmitry Igrishin <[email protected]>: > Hi, > > In "Internal position: this is defined the same as the P field, but it > is used when the cursor position refers to an internally generated", > "internally generated" should be replaced with "internally-generated". > https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html Yet another place with both of "internally generated" and "internall-generated" https://www.postgresql.org/docs/9.6/static/libpq-exec.html PS. By using FTS I see that there are another places with this inconsistency. -- // Dmitry. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 12:44 Kevin Grittner <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: Kevin Grittner @ 2016-06-07 12:44 UTC (permalink / raw) To: Dmitry Igrishin <[email protected]>; +Cc: pgsql-docs On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <[email protected]> wrote: > In "Internal position: this is defined the same as the P field, but it > is used when the cursor position refers to an internally generated", > "internally generated" should be replaced with "internally-generated". Not according to, for example, the Chicago Manual of Style: http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf (See the "adverb ending in ly + participle or adjective" category.) I'm pretty sure that this has been discussed on this list before and decided in favor of omitting the hyphenation in such cases. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 13:22 Dmitry Igrishin <[email protected]> parent: Kevin Grittner <[email protected]> 0 siblings, 2 replies; 20+ messages in thread From: Dmitry Igrishin @ 2016-06-07 13:22 UTC (permalink / raw) To: Kevin Grittner <[email protected]>; +Cc: pgsql-docs 2016-06-07 15:44 GMT+03:00 Kevin Grittner <[email protected]>: > On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <[email protected]> wrote: > >> In "Internal position: this is defined the same as the P field, but it >> is used when the cursor position refers to an internally generated", >> "internally generated" should be replaced with "internally-generated". > > Not according to, for example, the Chicago Manual of Style: > > http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf > > (See the "adverb ending in ly + participle or adjective" category.) > > I'm pretty sure that this has been discussed on this list before > and decided in favor of omitting the hyphenation in such cases. Hm, well, how about removing hypenation from "Internal query: the text of a failed internally-generated command", "procedural language functions and internally-generated queries", at https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html and similar in other places? -- // Dmitry. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 13:37 Kevin Grittner <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 0 replies; 20+ messages in thread From: Kevin Grittner @ 2016-06-07 13:37 UTC (permalink / raw) To: Dmitry Igrishin <[email protected]>; +Cc: pgsql-docs On Tue, Jun 7, 2016 at 8:22 AM, Dmitry Igrishin <[email protected]> wrote: > 2016-06-07 15:44 GMT+03:00 Kevin Grittner <[email protected]>: >> On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <[email protected]> wrote: >> >>> In "Internal position: this is defined the same as the P field, but it >>> is used when the cursor position refers to an internally generated", >>> "internally generated" should be replaced with "internally-generated". >> >> Not according to, for example, the Chicago Manual of Style: >> >> http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf >> >> (See the "adverb ending in ly + participle or adjective" category.) >> >> I'm pretty sure that this has been discussed on this list before >> and decided in favor of omitting the hyphenation in such cases. > Hm, well, how about removing hypenation from > "Internal query: the text of a failed internally-generated command", > "procedural language functions and internally-generated queries", > at https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html > and similar in other places? I think we should be consistent, especially on adjacent lines. Oddly, a single commit 12 years ago used both in close proximity. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 13:47 Tom Lane <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: Tom Lane @ 2016-06-07 13:47 UTC (permalink / raw) To: Dmitry Igrishin <[email protected]>; +Cc: Kevin Grittner <[email protected]>; pgsql-docs Dmitry Igrishin <[email protected]> writes: > 2016-06-07 15:44 GMT+03:00 Kevin Grittner <[email protected]>: >> I'm pretty sure that this has been discussed on this list before >> and decided in favor of omitting the hyphenation in such cases. > Hm, well, how about removing hypenation from > "Internal query: the text of a failed internally-generated command", > "procedural language functions and internally-generated queries", > at https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html > and similar in other places? They are both correct: it's just a matter of preference which one is used in a particular place. Any particular instance might be that way because whoever wrote it always writes that way, or maybe they actually thought about it and decided a hyphen did or didn't read better there. (To my taste, a hyphen is better if the phrase is being used as a compound adjective, and otherwise probably not; but it's a minor thing.) It's just make-work to try to make all the many hundreds of places where we have such wording 100% consistent; and I seriously doubt that it would create any improvement in readability. If you're looking to improve the docs, there are many places where the English is actually pretty bad ... but this isn't one. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo. @ 2016-06-07 14:20 Dmitry Igrishin <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Dmitry Igrishin @ 2016-06-07 14:20 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Kevin Grittner <[email protected]>; pgsql-docs 2016-06-07 16:47 GMT+03:00 Tom Lane <[email protected]>: > Dmitry Igrishin <[email protected]> writes: >> 2016-06-07 15:44 GMT+03:00 Kevin Grittner <[email protected]>: >>> I'm pretty sure that this has been discussed on this list before >>> and decided in favor of omitting the hyphenation in such cases. > >> Hm, well, how about removing hypenation from >> "Internal query: the text of a failed internally-generated command", >> "procedural language functions and internally-generated queries", >> at https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html >> and similar in other places? > > They are both correct: it's just a matter of preference which one is used > in a particular place. Any particular instance might be that way because > whoever wrote it always writes that way, or maybe they actually thought > about it and decided a hyphen did or didn't read better there. Hm, maybe. Shrug. > (To my taste, a hyphen is better if the phrase is being used as a compound > adjective, and otherwise probably not; but it's a minor thing.) Yes, I agree here. > It's just make-work to try to make all the many hundreds of places where we have > such wording 100% consistent; and I seriously doubt that it would create > any improvement in readability. > > If you're looking to improve the docs, there are many places where the > English is actually pretty bad ... but this isn't one. Well, I usually report here when I read the documentation to do my work and see some annoying inconsistency. And often I stop myself, but in certain cases I can't refrain not to report. Sorry if I too bother for things that don't worth it. -- // Dmitry. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 20+ messages in thread
* Typo @ 2020-01-29 07:36 PG Doc comments form <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PG Doc comments form @ 2020-01-29 07:36 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/libpq-ssl.html Description: On page https://www.postgresql.org/docs/11/libpq-ssl.html in phrase "if no Subject Alternative Name of type dNSName is present." dNSName should be DNSName ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2020-01-29 08:57 Magnus Hagander <[email protected]> parent: PG Doc comments form <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Magnus Hagander @ 2020-01-29 08:57 UTC (permalink / raw) To: [email protected]; Pg Docs <[email protected]> On Wed, Jan 29, 2020 at 9:55 AM PG Doc comments form <[email protected]> wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/libpq-ssl.html > Description: > > On page https://www.postgresql.org/docs/11/libpq-ssl.html in phrase "if no > Subject Alternative Name of type dNSName is present." dNSName should be > DNSName No, that documentation is actually correct. The field name is actually dNSName -- see https://tools.ietf.org/html/rfc5280 which defines it. It's somewhat ridiculous, but you have the same thing with iPAdress for example. I guess because the first letter has to be lowercase. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ ^ permalink raw reply [nested|flat] 20+ messages in thread
* Typo @ 2023-05-23 20:52 PG Doc comments form <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PG Doc comments form @ 2023-05-23 20:52 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] 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: https://www.postgresql.org/docs/current/history.html#:~:text=Postgres95%20code%20was%20completely%20.... A word or two should be added between 'completely' and 'ANSI C', such as 're-written in', or 're-coded using', or some such. Thanks, Peter Spung | Raleigh, NC, USA ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2023-05-23 22:32 Michael Paquier <[email protected]> parent: PG Doc comments form <[email protected]> 0 siblings, 2 replies; 20+ messages in thread From: Michael Paquier @ 2023-05-23 22:32 UTC (permalink / raw) To: [email protected]; [email protected] On Tue, May 23, 2023 at 08:52:25PM +0000, 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%20.... > A word or two should be added between 'completely' and 'ANSI C', such as > 're-written in', or 're-coded using', or some such. 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%. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2023-05-23 23:44 David G. Johnston <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 0 replies; 20+ messages in thread From: David G. Johnston @ 2023-05-23 23:44 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: [email protected]; [email protected] On Tue, May 23, 2023 at 3:32 PM Michael Paquier <[email protected]> wrote: > On Tue, May 23, 2023 at 08:52:25PM +0000, 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%20... > . > > A word or two should be added between 'completely' and 'ANSI C', such as > > 're-written in', or 're-coded using', or some such. > > 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%. > > I agree with the OP, that is missing something. Maybe: Between the 4.2 release and the release of Postgres95 the code was made to completely adhere to ANSI C and the size was reduced by 25%. David J. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2023-05-24 04:02 Laurenz Albe <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: Laurenz Albe @ 2023-05-24 04:02 UTC (permalink / raw) To: Michael Paquier <[email protected]>; [email protected]; [email protected] On Wed, 2023-05-24 at 07:32 +0900, Michael Paquier wrote: > On Tue, May 23, 2023 at 08:52:25PM +0000, 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%20.... > > A word or two should be added between 'completely' and 'ANSI C', such as > > 're-written in', or 're-coded using', or some such. > > 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 (even though English is somewhat relaxed about the distinction between classes of words). How about: "... was written completely in ANSI C ..." Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2023-05-24 04:25 Tom Lane <[email protected]> parent: Laurenz Albe <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Tom Lane @ 2023-05-24 04:25 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: Michael Paquier <[email protected]>; [email protected]; [email protected] Laurenz Albe <[email protected]> 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 > (even though English is somewhat relaxed about the distinction between > classes of words). Yeah, it's not great English, but it's not awful English either; just a rather telegraphic (abbreviated) style. Here's the thing: at this point, this documentation is itself a historical artifact. git excavation dates the current wording to 8baa8fcf4 of 1999-06-21, and that was just a small adjustment of c8cfb0cea of 1998-03-01, and it seems likely that that was pulled verbatim from some older source. So I'm disinclined to change it on grounds of "I think the grammar is a bit shaky". It is what it is. regards, tom lane ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2023-05-24 04:35 David G. Johnston <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: David G. Johnston @ 2023-05-24 04:35 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Michael Paquier <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> On Tuesday, May 23, 2023, Tom Lane <[email protected]> wrote: > Laurenz Albe <[email protected]> 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 > > (even though English is somewhat relaxed about the distinction between > > classes of words). > > Yeah, it's not great English, but it's not awful English either; > just a rather telegraphic (abbreviated) style. > > Here's the thing: at this point, this documentation is itself a > historical artifact. git excavation dates the current wording to > 8baa8fcf4 of 1999-06-21, and that was just a small adjustment of > c8cfb0cea of 1998-03-01, and it seems likely that that was pulled > verbatim from some older source. > > So I'm disinclined to change it on grounds of "I think the grammar > is a bit shaky". It is what it is. > > > Agreed. Besides, after a couple of more passes it grew on me, once I filled in the missing “compared to what” sufficiently. David J. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Typo @ 2026-02-19 06:57 PG Doc comments form <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PG Doc comments form @ 2026-02-19 06:57 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/18/indexes-types.html Description: There is a typo in the BRIN indexes definition—it says "INdexes" instead of "indexes." BRIN indexes (a shorthand for Block Range INdexes) ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Typo @ 2026-02-20 14:14 Daniel Gustafsson <[email protected]> parent: PG Doc comments form <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Daniel Gustafsson @ 2026-02-20 14:14 UTC (permalink / raw) To: [email protected]; [email protected] > On 19 Feb 2026, at 07:57, PG Doc comments form <[email protected]> wrote: > There is a typo in the BRIN indexes definition—it says "INdexes" instead of > "indexes." > > BRIN indexes (a shorthand for Block Range INdexes) It's spelled INdexes in that parenthesis to indicate what the acronym BRIN stands for. -- Daniel Gustafsson ^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2026-02-20 14:14 UTC | newest] Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2016-06-04 07:28 Typo [email protected] 2016-06-07 02:44 ` Michael Paquier <[email protected]> 2016-06-07 02:56 ` Tom Lane <[email protected]> 2016-06-07 11:26 Typo. Dmitry Igrishin <[email protected]> 2016-06-07 12:08 ` Re: Typo. Dmitry Igrishin <[email protected]> 2016-06-07 12:44 ` Re: Typo. Kevin Grittner <[email protected]> 2016-06-07 13:22 ` Re: Typo. Dmitry Igrishin <[email protected]> 2016-06-07 13:37 ` Re: Typo. Kevin Grittner <[email protected]> 2016-06-07 13:47 ` Re: Typo. Tom Lane <[email protected]> 2016-06-07 14:20 ` Re: Typo. Dmitry Igrishin <[email protected]> 2020-01-29 07:36 Typo PG Doc comments form <[email protected]> 2020-01-29 08:57 ` Magnus Hagander <[email protected]> 2023-05-23 20:52 Typo PG Doc comments form <[email protected]> 2023-05-23 22:32 ` Michael Paquier <[email protected]> 2023-05-23 23:44 ` David G. Johnston <[email protected]> 2023-05-24 04:02 ` Laurenz Albe <[email protected]> 2023-05-24 04:25 ` Tom Lane <[email protected]> 2023-05-24 04:35 ` David G. Johnston <[email protected]> 2026-02-19 06:57 Typo PG Doc comments form <[email protected]> 2026-02-20 14:14 ` Daniel Gustafsson <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox