public inbox for [email protected]help / color / mirror / Atom feed
Typo 12+ messages / 7 participants [nested] [flat]
* Typo @ 2016-06-04 07:28 [email protected] 0 siblings, 1 reply; 12+ 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] 12+ messages in thread
* Re: Typo @ 2016-06-07 02:44 Michael Paquier <[email protected]> parent: [email protected] 0 siblings, 1 reply; 12+ 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] 12+ messages in thread
* Re: Typo @ 2016-06-07 02:56 Tom Lane <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* Typo. @ 2016-06-07 11:26 Dmitry Igrishin <[email protected]> 0 siblings, 2 replies; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 12:08 Dmitry Igrishin <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 0 replies; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 12:44 Kevin Grittner <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 1 reply; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 13:22 Dmitry Igrishin <[email protected]> parent: Kevin Grittner <[email protected]> 0 siblings, 2 replies; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 13:37 Kevin Grittner <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 0 replies; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 13:47 Tom Lane <[email protected]> parent: Dmitry Igrishin <[email protected]> 1 sibling, 1 reply; 12+ 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] 12+ messages in thread
* Re: Typo. @ 2016-06-07 14:20 Dmitry Igrishin <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* Typo @ 2020-01-29 07:36 PG Doc comments form <[email protected]> 0 siblings, 1 reply; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
end of thread, other threads:[~2020-01-29 08:57 UTC | newest] Thread overview: 12+ 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]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox