Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation.
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation. |
Дата | |
Msg-id | 13949.1475499109@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Copy-editing for
contrib/pg_visibility documentation.
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Why do you keep insisting on changing case where I've written "which" > to instead say "that" in situations where AFAIK either is perfectly > correct? I find such changes at best neutral, and in some cases > worse. What I was taught in school was that "that" introduces a restrictive clause, i.e. one that limits the membership of whatever group was just mentioned, while "which" introduces a descriptive clause, i.e. one that just provides more information about the group. So for example Functions that return a pass-by-reference type must do X. is correct, while Functions, which return a pass-by-reference type, must do X. carries an implication that *all* functions in the system return pass-by-reference types. Even if you think that that's obviously silly, it may confuse readers who are accustomed to this distinction being drawn. On the other hand, this is fine: Functions that return text, which is a pass-by-reference type,must do X. I've made the point more obvious in the above by setting off descriptive clauses with commas, which is a common thing to do. But the punctuation is optional. I realize that this is nitpickery, and wouldn't usually bother about the distinction in, say, code comments. But we are striving to be somewhat formal in the user-facing documentation, no? regards, tom lane
В списке pgsql-hackers по дате отправления: