Thread: Typo.
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.
2016-06-07 14:26 GMT+03:00 Dmitry Igrishin <dmitigr@gmail.com>: > 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.
On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <dmitigr@gmail.com> 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
2016-06-07 15:44 GMT+03:00 Kevin Grittner <kgrittn@gmail.com>: > On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <dmitigr@gmail.com> 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.
On Tue, Jun 7, 2016 at 8:22 AM, Dmitry Igrishin <dmitigr@gmail.com> wrote: > 2016-06-07 15:44 GMT+03:00 Kevin Grittner <kgrittn@gmail.com>: >> On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin <dmitigr@gmail.com> 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
Dmitry Igrishin <dmitigr@gmail.com> writes: > 2016-06-07 15:44 GMT+03:00 Kevin Grittner <kgrittn@gmail.com>: >> 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
2016-06-07 16:47 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>: > Dmitry Igrishin <dmitigr@gmail.com> writes: >> 2016-06-07 15:44 GMT+03:00 Kevin Grittner <kgrittn@gmail.com>: >>> 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.