Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation.
Date: 2016-10-03 12:51:49
Message-ID: 13949.1475499109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-10-03 13:49:37 Re: [COMMITTERS] pgsql: Copy-editing for contrib/pg_visibility documentation.
Previous Message Heikki Linnakangas 2016-10-03 10:38:53 pgsql: Change the way pre-reading in external sort's merge phase works.

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2016-10-03 12:52:44 Re: pageinspect: Hash index support
Previous Message Christoph Berg 2016-10-03 12:46:46 Re: pgbench - allow backslash continuations in \set expressions