Make primnodes.h gender neutral
Per the twitter verse, here is an updated version of primnodes.h
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Attachments:
primnodes.difftext/x-patch; name=primnodes.diffDownload
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index f942378..827699d 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -1,4 +1,4 @@
-/*-------------------------------------------------------------------------
+
*
* primnodes.h
* Definitions for "primitive" node types, those that are used in more
@@ -1326,10 +1326,10 @@ typedef struct RangeTblRef
*
* isNatural, usingClause, and quals are interdependent. The user can write
* only one of NATURAL, USING(), or ON() (this is enforced by the grammar).
- * If he writes NATURAL then parse analysis generates the equivalent USING()
+ * If one writes NATURAL then parse analysis generates the equivalent USING()
* list, and from that fills in "quals" with the right equality comparisons.
- * If he writes USING() then "quals" is filled with equality comparisons.
- * If he writes ON() then only "quals" is set. Note that NATURAL/USING
+ * If one writes USING() then "quals" is filled with equality comparisons.
+ * If one writes ON() then only "quals" is set. Note that NATURAL/USING
* are not equivalent to ON() since they also affect the output column list.
*
* alias is an Alias node representing the AS alias-clause attached to the
On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Per the twitter verse, here is an updated version of primnodes.h
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Per the twitter verse, here is an updated version of primnodes.h
+1.
+1 what? Are you saying this patch is good? I don't think it is: the
previous sentence is written in third person, and the following ones are
currently in third person, but the patch changes the following sentences
to first person without changing the first one to match. If he or she
(or they) want this updated, I think we should at least make an effort
of keeping it as consistent as it is today.
I *hope* this isn't the start of a trend to patch 1500 files one by one,
each on its own thread. That's going to be annoying and noisy, achieve
nothing useful(*), and cause backpatching pain that the "twitter
verse"(**) is not going to help with.
(*) I'm probably going to be expelled from the project for saying this,
but I very much doubt that female coders stay away from PostgreSQL just
because some files say "he" in comments rather than "she" or "he or she"
or "one" or "they". They probably have different reasons for staying
away from the project.
(**) "Verse" is a word, but it doesn't mean what you seem to think it
does.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
Robert Haas wrote:
On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Per the twitter verse, here is an updated version of primnodes.h
+1.
+1 what? Are you saying this patch is good? I don't think it is: the
previous sentence is written in third person, and the following ones are
currently in third person, but the patch changes the following sentences
to first person without changing the first one to match. If he or she
(or they) want this updated, I think we should at least make an effort
of keeping it as consistent as it is today.
The wording was Meh to begin with. If you would like me to spend some
time cleaning up the paragraph as a whole, I will do that.
I *hope* this isn't the start of a trend to patch 1500 files one by one,
each on its own thread. That's going to be annoying and noisy, achieve
nothing useful(*), and cause backpatching pain that the "twitter
verse"(**) is not going to help with.
So we have two choices I see:
1. As we come across the gender issue, we fix it as well as incorporate
a gender neutral requirement for all documentation unless the gender is
relevant to the context.
2. We do "one big patch".
#2 seems to be a really bad idea.
(*) I'm probably going to be expelled from the project for saying this,
but I very much doubt that female coders stay away from PostgreSQL just
because some files say "he" in comments rather than "she" or "he or she"
or "one" or "they". They probably have different reasons for staying
away from the project.
Wanna bet? There is a very loud movement about this. We can either:
A. Start fighting about it
B. Just fix it, it doesn't matter anyway and it doesn't hurt the quality
of the code or the documentation
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
+1 what? Are you saying this patch is good? I don't think it is: the
previous sentence is written in third person, and the following ones are
currently in third person, but the patch changes the following sentences
to first person without changing the first one to match. If he or she
(or they) want this updated, I think we should at least make an effort
of keeping it as consistent as it is today.
The wording was Meh to begin with. If you would like me to spend some
time cleaning up the paragraph as a whole, I will do that.
I think it's important that we fix these issues in a way that doesn't
degrade the readability of the prose, and that doesn't call attention
to itself as "hey, we're being so politically correct!". We're trying
to convey technical information in a way that does not distract the
reader from the technical content. Sexist language is a distraction
for some, in-your-face non-sexism (such as made-up pronouns) is a
distraction for others, bad or awkward grammar is a distraction for yet
others. It's not that easy to write prose that manages not to call
attention to itself in any of these ways. But that's what we need to
do, and s/xxx/yyy/g editing that's only thinking about one of these
concerns is unlikely to get us there.
I also concur with Alvaro that fixing these issues one para at a time
is pretty inefficient.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/17/2016 02:11 PM, Tom Lane wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
+1 what? Are you saying this patch is good? I don't think it is: the
previous sentence is written in third person, and the following ones are
currently in third person, but the patch changes the following sentences
to first person without changing the first one to match. If he or she
(or they) want this updated, I think we should at least make an effort
of keeping it as consistent as it is today.The wording was Meh to begin with. If you would like me to spend some
time cleaning up the paragraph as a whole, I will do that.I think it's important that we fix these issues in a way that doesn't
degrade the readability of the prose,
I don't disagree.
and that doesn't call attention
to itself as "hey, we're being so politically correct!". We're trying
to convey technical information in a way that does not distract the
reader from the technical content. Sexist language is a distraction
for some, in-your-face non-sexism (such as made-up pronouns) is a
distraction for others, bad or awkward grammar is a distraction for yet
others.
I also concur with Alvaro that fixing these issues one para at a time
is pretty inefficient.
How else are we going to do it? If we use sed, we are basically going to
end up with the "hey, we're being so politically correct!" issue. The
only other way I can think to fix it is to fix it as we come across it.
If you are in a file and see the gender issue, just fix it as part of
the patch you are working on.
JD
regards, tom lane
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18/03/16 09:41, Joshua D. Drake wrote:
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
[...]
(*) I'm probably going to be expelled from the project for saying this,
but I very much doubt that female coders stay away from PostgreSQL just
because some files say "he" in comments rather than "she" or "he or she"
or "one" or "they". They probably have different reasons for staying
away from the project.Wanna bet? There is a very loud movement about this. We can either:
A. Start fighting about it
B. Just fix it, it doesn't matter anyway and it doesn't hurt the
quality of the code or the documentationJD
I strongly think that gender should not be mentioned unless it is
relevant - as constructs like 'he or she' are clumsy and distract from
what is being commented on, not to mention that some rare people are:
neither, both, or ambiguous (from research I did when I read a rather
curious article).
Other than 'one', 'their', 'they', &' them' - there are role specific
references like 'user', 'developer', & 'DBA', ... that can be used where
appropriate.
I tend to prefer the term 'Gender Appropriate' rather than 'Gender
Neutral', as sometimes mentioning gender IS very relevant!
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 17, 2016 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I think it's important that we fix these issues in a way that doesn't
degrade the readability of the prose, and that doesn't call attention
to itself as "hey, we're being so politically correct!". We're trying
to convey technical information in a way that does not distract the
reader from the technical content. Sexist language is a distraction
for some, in-your-face non-sexism (such as made-up pronouns) is a
distraction for others, bad or awkward grammar is a distraction for yet
others. It's not that easy to write prose that manages not to call
attention to itself in any of these ways. But that's what we need to
do, and s/xxx/yyy/g editing that's only thinking about one of these
concerns is unlikely to get us there.
+1
I also concur with Alvaro that fixing these issues one para at a time
is pretty inefficient.
A grep with a quick skim of the results to exclude references to
particular people who are mentioned by name and then referred to
with a pronoun (which I assume we can leave alone), suggest there
are about 70 lines in the 1346667 line C code base that need work.
Any word-smiths out there who want to volunteer to sort this out?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 17, 2016 at 2:17 PM, Gavin Flower <GavinFlower@archidevsys.co.nz
wrote:
On 18/03/16 09:41, Joshua D. Drake wrote:
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
[...]
(*) I'm probably going to be expelled from the project for saying this,
but I very much doubt that female coders stay away from PostgreSQL just
because some files say "he" in comments rather than "she" or "he or she"
or "one" or "they". They probably have different reasons for staying
away from the project.Wanna bet? There is a very loud movement about this. We can either:
A. Start fighting about it
B. Just fix it, it doesn't matter anyway and it doesn't hurt the quality
of the code or the documentationJD
I strongly think that gender should not be mentioned unless it is relevant
- as constructs like 'he or she' are clumsy and distract from what is being
commented on, not to mention that some rare people are: neither, both, or
ambiguous (from research I did when I read a rather curious article).Other than 'one', 'their', 'they', &' them' - there are role specific
references like 'user', 'developer', & 'DBA', ... that can be used where
appropriate.I tend to prefer the term 'Gender Appropriate' rather than 'Gender
Neutral', as sometimes mentioning gender IS very relevant!
That's only half the issue. If some people want to review every new patch
for gender appropriateness and point out any problems before those patches
get committed I'm doubting anyone is going to complain.
The question here is whether we should fix the wording of a comment that
was added in, and exists unchanged since, 7.2
IMO we can be more sensitive to these issues in the present without having
to apologize for (and fix) this project's history and the writing of people
who may no longer even be around. Hopefully this compromise position is
sufficiently accommodating - I am personally fine if the people with real
control decide to operate under this premise.
If we are going to make a concerted effort to change historical writing we
might as well just take the hit and "s/he/one/g". Later, if someone
reading the revised wording finds it distasteful they can fix those
instances that are so egregious or presently-relevant to warrant the effort.
If we do this how many new developers are we expecting to subscribe to the
-hackers list and make serious contributions - say, by reviewing the large
backlog of patches we presently have?
David J.
On Thu, Mar 17, 2016 at 4:34 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
If we do this how many new developers are we expecting to subscribe to the
-hackers list and make serious contributions - say, by reviewing the large
backlog of patches we presently have?
I would certainly welcome even one new contributor who would do
this without causing any new feature to slip from the next release.
;-)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Joshua D. Drake wrote:
On 03/17/2016 01:36 PM, Alvaro Herrera wrote:
Robert Haas wrote:
On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Per the twitter verse, here is an updated version of primnodes.h
+1.
+1 what? Are you saying this patch is good? I don't think it is: the
previous sentence is written in third person, and the following ones are
currently in third person, but the patch changes the following sentences
to first person without changing the first one to match. If he or she
(or they) want this updated, I think we should at least make an effort
of keeping it as consistent as it is today.The wording was Meh to begin with. If you would like me to spend some time
cleaning up the paragraph as a whole, I will do that.
I'd rather you left it alone until we had some other reason to change
that text, then reword it completely.
I *hope* this isn't the start of a trend to patch 1500 files one by one,
each on its own thread. That's going to be annoying and noisy, achieve
nothing useful(*), and cause backpatching pain that the "twitter
verse"(**) is not going to help with.So we have two choices I see:
1. As we come across the gender issue, we fix it as well as incorporate a
gender neutral requirement for all documentation unless the gender is
relevant to the context.
I support the idea of changing our user-visible docs, error messages etc
to be gender neutral, but going down to comments in header files seems
pointless -- until those comments need to be rewritten for some
different reason.
2. We do "one big patch".
#2 seems to be a really bad idea.
Sure.
(*) I'm probably going to be expelled from the project for saying this,
but I very much doubt that female coders stay away from PostgreSQL just
because some files say "he" in comments rather than "she" or "he or she"
or "one" or "they". They probably have different reasons for staying
away from the project.Wanna bet? There is a very loud movement about this.
I don't doubt that there's a lot of people with a lot of time in their
hands. No doubt they are loud, either.
Are they going to contribute something actually useful after we fix all
the "he" in the code comments? That's the part that I don't believe. I
mean new features, bug fixes, more tests, code refactoring, better
system integration, new drivers -- whatever. Heck, are they going to
answer more questions in mailing lists?
Anyway, this is a -1 from me. If others decide that this is important
and want to do the job, that's fine; I can deal with the conflicts.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/17/16 17:29, Kevin Grittner wrote:
On Thu, Mar 17, 2016 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Sexist language is a distraction
for some, in-your-face non-sexism (such as made-up pronouns) is a
distraction for others, bad or awkward grammar is a distraction for yet
others. It's not that easy to write prose that manages not to call
attention to itself in any of these ways. But that's what we need to
do, and s/xxx/yyy/g editing that's only thinking about one of these
concerns is unlikely to get us there.+1
^^^ I would have said that if I'd been fast enough.
A grep with a quick skim of the results to exclude references to
particular people who are mentioned by name and then referred to
with a pronoun (which I assume we can leave alone), suggest there
are about 70 lines in the 1346667 line C code base that need work.Any word-smiths out there who want to volunteer to sort this out?
So that must be N affected files for some N <= 70 ...
what would you think of starting a wiki page with those N filenames
(so nobody has to repeat your grepping/skimming effort), and volunteers
can claim a file or five, marking them taken on that page, and wordsmith
away?
On 03/17/16 17:17, Gavin Flower wrote:
Wanna bet? There is a very loud movement about this.
For those of us who are outside of the twitterverse sort of on purpose,
are there a few representative links you could post? Maybe this is such
fresh breaking news Google hasn't spidered it yet, but I didn't find
any reference to the primnodes language when I looked, and I really am
curious to see just exactly what kind of issue is being made around it....
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
On 03/17/16 17:29, Kevin Grittner wrote:
A grep with a quick skim of the results to exclude references to
particular people who are mentioned by name and then referred to
with a pronoun (which I assume we can leave alone), suggest there
are about 70 lines in the 1346667 line C code base that need work.Any word-smiths out there who want to volunteer to sort this out?
So that must be N affected files for some N <= 70 ...
what would you think of starting a wiki page with those N filenames
(so nobody has to repeat your grepping/skimming effort), and volunteers
can claim a file or five, marking them taken on that page, and wordsmith
away?
Yeah, Kevin, could you post your results? I'd have guessed there were
more trouble spots than that. If that really is the size of the problem,
seems like we could fix all those instances in one patch and be done
with it. (At least till new ones sneak in :-()
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack <chap@anastigmatix.net> wrote:
For those of us who are outside of the twitterverse sort of on purpose,
are there a few representative links you could post? Maybe this is such
fresh breaking news Google hasn't spidered it yet, but I didn't find
any reference to the primnodes language when I looked, and I really am
curious to see just exactly what kind of issue is being made around it....
Not to pick on you in particular, but rather in general response to
everyone who has expressed doubt about this idea:
Debating whether or not somebody is currently upset about this, and
how upset the are, and what the value is of fixing it is missing the
point. When somebody sends a patch for a typographical error, we
don't say: well, we could fix that typographical error, but let's wait
until the next time we have cause to reword the paragraph. We just
commit the patch. Now, I realize this is not quite the same thing,
because, as Tom rightly points out, it is possible to degrade the
readability of comments or documentation in the pursuit of political
correctness, and we should not do that. On the other hand, if we
found a comment somewhere in our source code that implied that all of
our users were white, or that they were all English-speaking, or that
one American political party was more worthy than the other, we
wouldn't sit around debating whether it was worth the effort to fix
it. We would just fix it, even if it meant changing a few surrounding
words rather than just one or two. And it wouldn't be that much work,
and it wouldn't cause major features to slip out of the release, and
it wouldn't be a waste of time.
Similarly here. The comment implies that the user is male. It
shouldn't. Let's fix it in whatever way is most expedient and move
on. If at some point we are overwhelmed with a slough of patches
making similar changes, we can at that time ask for them to be
consolidated, just as we would do for typo fixes, grammar fixes, or
warning fixes. It is not necessary to insist on that that now because
we are not faced with any such issue at this time. If we gain a
reputation as a community that is not willing to make reasonable
efforts to use gender-neutral language, it will hurt us far more than
the comment itself. Let's not go there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mar 17, 2016, at 12:31 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Per the twitter verse, here is an updated version of primnodes.h
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
<primnodes.diff>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I don't have any political opinion about this sort of thing, but I'd rather
core developers don't waste any time on it. Let me get you a patch
that covers this, and if nobody objects I'll attempt to back patch it and
submit that, too. If nobody likes the changes, I won't mind throwing
them out; as I said, I don't have an opinion on the politics.
Please, don't waste your time if you have actual features to implement.
Regards,
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 17, 2016 at 4:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Debating whether or not somebody is currently upset about this, and
how upset the are, and what the value is of fixing it is missing the
point. When somebody sends a patch for a typographical error, we
don't say: well, we could fix that typographical error, but let's wait
until the next time we have cause to reword the paragraph. We just
commit the patch
Right. We could spend significant time debating how much this matters.
I expect that few if any contributors would consider that a policy on
gendered pronouns has negative value, though, and it really isn't that
hard to fix. So we should just fix it.
(In case it matters, I'm in favor of this proposal on its merits).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
(In case it matters, I'm in favor of this proposal on its merits).
For the record, I'm also in favor of fixing that para, but I'd like
to see attention paid to grammatical correctness as well as political.
Alvaro's original complaint that the sentences no longer agree as to
person is on-point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/17/16 19:09, Robert Haas wrote:
On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack <chap@anastigmatix.net> wrote:
Not to pick on you in particular...
Debating whether or not somebody is currently upset about this, and
how upset the are, and what the value is of fixing it is missing the
point.
Well, looking at my response in particular, you can see that I *began
it* with concrete constructive suggestions about fixing it, so that was
never part of the question. (I work pretty hard at non-obtrusively-gendered
language myself, I'm from a region/era where that was a thing to strive
for so it feels natural to me ... not that I never have something slip out
that someone might object to, but most obviously gendered usages already
sound funny to me, so by and large I avoid them.)
It was only in the later part of my comment that I asked for a link,
and even there I said nothing about "whether or not somebody is currently
upset", and certainly not "Is it ridiculous?" as in Joshua's response to
me. I just wanted a chance to read the comments in question, because
I hadn't been able to google them, and I *wanted the chance to get familiar
with the opinions and arguments of those vocally concerned in their own
words* ... because that's a thing I like to do.
So Joshua included the link, so I'll go read now.... :)
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro's original complaint that the sentences no longer agree as to
person is on-point.
That's reasonable. Still, there are only a few existing instances of
gendered pronouns in the code, so fixing them carefully, without
losing anything important seems like a relatively straightforward
task.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thursday, March 17, 2016, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack <chap@anastigmatix.net
<javascript:;>> wrote:For those of us who are outside of the twitterverse sort of on purpose,
are there a few representative links you could post? Maybe this is such
fresh breaking news Google hasn't spidered it yet, but I didn't find
any reference to the primnodes language when I looked, and I really am
curious to see just exactly what kind of issue is being made aroundit....
Similarly here. The comment implies that the user is male. It
shouldn't. Let's fix it in whatever way is most expedient and move
on. If at some point we are overwhelmed with a slough of patches
making similar changes, we can at that time ask for them to be
consolidated, just as we would do for typo fixes, grammar fixes, or
warning fixes. It is not necessary to insist on that that now because
we are not faced with any such issue at this time. If we gain a
reputation as a community that is not willing to make reasonable
efforts to use gender-neutral language, it will hurt us far more than
the comment itself. Let's not go there.
And if someone had just posted the patch and not prefaced it "we need to
check all of our comments for gender usage" it probably would have slipped
thorough without comment.
But that isn't what happened and since, based upon previous comments, we
expected many other commits of this sort we rightly discussed how to do
it. The original author indeed figured one patch per file was probably a
good way to do things but I can others would seem to prefer one targeted
patch.
Beyond that it's the usual bike shedding when it comes to writing...which
was the original contra-vote.
David J.
On Mar 17, 2016, at 5:05 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro's original complaint that the sentences no longer agree as to
person is on-point.That's reasonable. Still, there are only a few existing instances of
gendered pronouns in the code, so fixing them carefully, without
losing anything important seems like a relatively straightforward
task.
I have compiled a list of all the ones I found, manually excluding instances
where the pronoun is appropriate:
./configure.in
--------------
line 751: # so we make the user say which one she wants.
./doc/src/sgml/release-7.4.sgml
-------------------------------
line 223: a database he owns, this would remove all special parameter settings
./doc/src/sgml/release-8.0.sgml
-------------------------------
line 293: a database he owns, this would remove all special parameter settings
./doc/src/sgml/release-8.1.sgml
-------------------------------
line 520: a database he owns, this would remove all special parameter settings
line 3446: Once a user logs into a role, she obtains capabilities of
line 3448: <command>SET ROLE</> to switch to other roles she is a member of.
./doc/src/sgml/release-8.2.sgml
-------------------------------
line 1423: a database he owns, this would remove all special parameter settings
./doc/src/sgml/release-8.3.sgml
-------------------------------
line 1072: function with forged input data, by installing it on a table he owns.
line 2996: a database he owns, this would remove all special parameter settings
./doc/src/sgml/release-8.4.sgml
-------------------------------
line 492: revoke the access of others, contrary to the wishes of his grantor.
line 494: uncooperative role member could provide most of his rights to others
line 2719: function with forged input data, by installing it on a table he owns.
line 5223: a database he owns, this would remove all special parameter settings
./doc/src/sgml/release-9.0.sgml
-------------------------------
line 1220: within a command parameter might succeed in injecting his own SQL
line 2382: revoke the access of others, contrary to the wishes of his grantor.
line 2384: uncooperative role member could provide most of his rights to others
line 5089: function with forged input data, by installing it on a table he owns.
./doc/src/sgml/release-9.1.sgml
-------------------------------
line 1867: within a command parameter might succeed in injecting his own SQL
line 3164: revoke the access of others, contrary to the wishes of his grantor.
line 3166: uncooperative role member could provide most of his rights to others
line 6551: function with forged input data, by installing it on a table he owns.
./doc/src/sgml/release-9.2.sgml
-------------------------------
line 2006: within a command parameter might succeed in injecting his own SQL
line 3521: revoke the access of others, contrary to the wishes of his grantor.
line 3523: uncooperative role member could provide most of his rights to others
./doc/src/sgml/release-9.3.sgml
-------------------------------
line 2273: within a command parameter might succeed in injecting his own SQL
line 5641: revoke the access of others, contrary to the wishes of his grantor.
line 5643: uncooperative role member could provide most of his rights to others
./doc/src/sgml/release-9.4.sgml
-------------------------------
line 4394: within a command parameter might succeed in injecting his own SQL
./doc/src/sgml/user-manag.sgml
------------------------------
line 132: need not match his or her real name.) Since the role
./src/backend/access/hash/README
--------------------------------
line 446: page acquirer will scan more bitmap bits than he needs to. What must be
./src/backend/access/heap/heapam.c
----------------------------------
line 5274: * It's a committed update, so we need to preserve him as updater of
line 5381: * It's a committed update, so we gotta preserve him as updater of the
line 6557: * the VACUUM and perhaps truncate off the part of pg_clog he needs. Getting
./src/backend/access/index/genam.c
----------------------------------
line 48: * whatever kind of locking he wants.
./src/backend/access/transam/README
-----------------------------------
line 108: she sees and types ABORT (syntax error, etc)
./src/backend/access/transam/twophase.c
---------------------------------------
line 624: * yet. The caller should filter them out if he doesn't want them.
./src/backend/access/transam/xact.c
-----------------------------------
line 3004: * will interpret the error as meaning the BEGIN failed to get him
./src/backend/access/transam/xlog.c
-----------------------------------
line 8386: * we wait till he's out of his commit critical section before proceeding.
line 8399: * risk, since he's not inserted his commit record yet; and one that's
line 8400: * already cleared it is not at risk either, since he's done fixing clog
line 10498: * knowledge of those mechanisms, so it's up to the user to ensure that he
line 10507: * assume the admin wanted his backup to work completely. If you don't
./src/backend/catalog/aclchk.c
------------------------------
line 175: * The reason is that if a user would re-grant a privilege that he
line 1004: * he has that, he could become that role anyway via SET ROLE, so
line 1049: * allow the ALTER; if the user lacks CREATE he'll find out when
line 1050: * he tries to create an object.
./src/backend/catalog/pg_shdepend.c
-----------------------------------
line 449: * Skip the owner: he has an OWNER shdep entry instead. (This is
./src/backend/commands/indexcmds.c
----------------------------------
line 1358: * to specify which one he wants. (The preferred-type special case is a
./src/backend/commands/user.c
-----------------------------
line 1014: * Lock the role, so nobody can add dependencies to her while we drop
line 1015: * her. We keep the lock until the end of transaction.
./src/backend/commands/vacuum.c
-------------------------------
line 1266: * We allow the user to vacuum a table if he is superuser, the table
./src/backend/executor/execQual.c
---------------------------------
line 5483: * data will be valid, he must call ExecMaterializeSlot on the
./src/backend/executor/functions.c
----------------------------------
line 1489: * to be sure that the user is returning the type he claims. There are
./src/backend/libpq/auth.c
--------------------------
line 1393: * owns the tcp connection from his port "remote_port" to port
./src/backend/libpq/hba.c
-------------------------
line 6: * says he comes from and choosing authentication method based on it).
./src/backend/nodes/makefuncs.c
-------------------------------
line 247: * We always set these fields to 0. If the caller wants to change them he
./src/backend/optimizer/plan/planner.c
--------------------------------------
line 276: * from a cursor, but it is often the case that he doesn't want 'em
line 277: * all, or would prefer a fast-start plan anyway so that he can
./src/backend/parser/parse_clause.c
-----------------------------------
line 1631: * since the user didn't write them in his SELECT list.
line 2004: * used by GROUP BY, should she be working with a datatype that has
line 2523: * should she be working with a datatype that has more than one equality
line 2612: * should she be working with a datatype that has more than one equality
./src/backend/port/sysv_sema.c
------------------------------
line 256: * sema key before we did. Let him have that one, loop around to try
./src/backend/port/sysv_shmem.c
-------------------------------
line 534: * shmem key before we did. Let him have that one, loop around to try
./src/backend/postmaster/autovacuum.c
-------------------------------------
line 1670: * Wake the launcher up so that he can launch a new worker immediately
line 2870: * All we do here is annoy the user if he got it wrong.
./src/backend/postmaster/pgarch.c
---------------------------------
line 333: * signal ... however, the archiver exists to protect our data, so she
./src/backend/postmaster/pgstat.c
---------------------------------
line 938: * Will tell the collector about objects he can get rid of.
./src/backend/postmaster/postmaster.c
-------------------------------------
line 4137: * process for nearly twice AuthenticationTimeout before we kick him off.
./src/backend/regex/regerror.c
------------------------------
line 88: { /* unknown; tell him the number */
./src/backend/storage/buffer/bufmgr.c
-------------------------------------
line 3695: * io_in_progress lock until he's done.
line 3726: * him to get unwedged.
./src/backend/storage/buffer/freelist.c
---------------------------------------
line 599: * buffer with the normal allocation strategy. He will then fill this
line 629: * strategy. He'll then replace this ring element via AddBufferToRing.
./src/backend/storage/ipc/sinvaladt.c
-------------------------------------
line 680: * him into reset state and then ignore until he catches up.
line 685: /* no point in signaling him ... */
./src/backend/storage/lmgr/lock.c
---------------------------------
line 1469: * some waiter, who could now be awakened because he doesn't conflict with
line 1470: * his own locks.
./src/backend/storage/lmgr/proc.c
---------------------------------
line 149: * than his kernel will support, he'll find out sooner rather than later.
line 1063: /* Must he wait for me? */
line 1066: /* Must I wait for him ? */
line 1092: /* Break out of loop to put myself before him */
line 1599: * Cannot wake this guy. Remember his request for later checks.
./src/backend/tcop/pquery.c
---------------------------
line 500: * Fire her up according to the strategy
./src/backend/utils/adt/acl.c
-----------------------------
line 819: * options. This is because his grant options come "from the system" and
line 820: * not from his own efforts. (The SQL spec says that the owner's rights
line 822: * owner's ordinary privileges are self-granted; this lets him revoke
line 4939: * FROM carol". If he creates an expression index calling that
./src/backend/utils/adt/ruleutils.c
-----------------------------------
line 2080: * shouldn't use a short delimiter that he might easily create a conflict
./src/backend/utils/cache/plancache.c
-------------------------------------
line 1313: /* OK, let the caller keep the plan where he wishes */
./src/backend/utils/fmgr/fmgr.c
-------------------------------
line 2484: * calls to validators that he could not achieve with CREATE FUNCTION or by
./src/bin/pg_dump/pg_backup_directory.c
---------------------------------------
line 47: * Our archive location. This is basically what the user specified as his
./src/common/pg_lzcompress.c
----------------------------
line 160: * is omitted and only his history entry added.
./src/include/c.h
-----------------
line 868: * that the pointer is suitably aligned (typically, because he just got it
./src/include/nodes/primnodes.h
-------------------------------
line 1329: * If he writes NATURAL then parse analysis generates the equivalent USING()
line 1331: * If he writes USING() then "quals" is filled with equality comparisons.
line 1332: * If he writes ON() then only "quals" is set. Note that NATURAL/USING
./src/interfaces/libpq/fe-lobj.c
--------------------------------
line 165: * function being available, he could have called lo_truncate64 for
./src/interfaces/libpq/fe-secure-openssl.c
------------------------------------------
line 750: * If the caller has told us (through PQinitOpenSSL) that he's taking care
./src/nls-global.mk
-------------------
line 30: # If user specified the languages he wants in --enable-nls=LANGUAGES,
./src/test/regress/expected/dependency.out
------------------------------------------
line 26: -- now we are OK to drop him
./src/test/regress/sql/dependency.sql
-------------------------------------
line 27: -- now we are OK to drop him
./src/tools/msvc/README
-----------------------
line 89: (i. e. path to bison and flex). In addition his config.pl file is merged into
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mar 17, 2016, at 5:40 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
On Mar 17, 2016, at 5:05 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro's original complaint that the sentences no longer agree as to
person is on-point.That's reasonable. Still, there are only a few existing instances of
gendered pronouns in the code, so fixing them carefully, without
losing anything important seems like a relatively straightforward
task.I have compiled a list of all the ones I found, manually excluding instances
where the pronoun is appropriate:./configure.in
--------------
line 751: # so we make the user say which one she wants../doc/src/sgml/release-7.4.sgml
-------------------------------
line 223: a database he owns, this would remove all special parameter settings./doc/src/sgml/release-8.0.sgml
-------------------------------
line 293: a database he owns, this would remove all special parameter settings./doc/src/sgml/release-8.1.sgml
-------------------------------
line 520: a database he owns, this would remove all special parameter settings
line 3446: Once a user logs into a role, she obtains capabilities of
line 3448: <command>SET ROLE</> to switch to other roles she is a member of../doc/src/sgml/release-8.2.sgml
-------------------------------
line 1423: a database he owns, this would remove all special parameter settings./doc/src/sgml/release-8.3.sgml
-------------------------------
line 1072: function with forged input data, by installing it on a table he owns.
line 2996: a database he owns, this would remove all special parameter settings./doc/src/sgml/release-8.4.sgml
-------------------------------
line 492: revoke the access of others, contrary to the wishes of his grantor.
line 494: uncooperative role member could provide most of his rights to others
line 2719: function with forged input data, by installing it on a table he owns.
line 5223: a database he owns, this would remove all special parameter settings./doc/src/sgml/release-9.0.sgml
-------------------------------
line 1220: within a command parameter might succeed in injecting his own SQL
line 2382: revoke the access of others, contrary to the wishes of his grantor.
line 2384: uncooperative role member could provide most of his rights to others
line 5089: function with forged input data, by installing it on a table he owns../doc/src/sgml/release-9.1.sgml
-------------------------------
line 1867: within a command parameter might succeed in injecting his own SQL
line 3164: revoke the access of others, contrary to the wishes of his grantor.
line 3166: uncooperative role member could provide most of his rights to others
line 6551: function with forged input data, by installing it on a table he owns../doc/src/sgml/release-9.2.sgml
-------------------------------
line 2006: within a command parameter might succeed in injecting his own SQL
line 3521: revoke the access of others, contrary to the wishes of his grantor.
line 3523: uncooperative role member could provide most of his rights to others./doc/src/sgml/release-9.3.sgml
-------------------------------
line 2273: within a command parameter might succeed in injecting his own SQL
line 5641: revoke the access of others, contrary to the wishes of his grantor.
line 5643: uncooperative role member could provide most of his rights to others./doc/src/sgml/release-9.4.sgml
-------------------------------
line 4394: within a command parameter might succeed in injecting his own SQL./doc/src/sgml/user-manag.sgml
------------------------------
line 132: need not match his or her real name.) Since the role./src/backend/access/hash/README
--------------------------------
line 446: page acquirer will scan more bitmap bits than he needs to. What must be./src/backend/access/heap/heapam.c
----------------------------------
line 5274: * It's a committed update, so we need to preserve him as updater of
line 5381: * It's a committed update, so we gotta preserve him as updater of the
line 6557: * the VACUUM and perhaps truncate off the part of pg_clog he needs. Getting./src/backend/access/index/genam.c
----------------------------------
line 48: * whatever kind of locking he wants../src/backend/access/transam/README
-----------------------------------
line 108: she sees and types ABORT (syntax error, etc)./src/backend/access/transam/twophase.c
---------------------------------------
line 624: * yet. The caller should filter them out if he doesn't want them../src/backend/access/transam/xact.c
-----------------------------------
line 3004: * will interpret the error as meaning the BEGIN failed to get him./src/backend/access/transam/xlog.c
-----------------------------------
line 8386: * we wait till he's out of his commit critical section before proceeding.
line 8399: * risk, since he's not inserted his commit record yet; and one that's
line 8400: * already cleared it is not at risk either, since he's done fixing clog
line 10498: * knowledge of those mechanisms, so it's up to the user to ensure that he
line 10507: * assume the admin wanted his backup to work completely. If you don't./src/backend/catalog/aclchk.c
------------------------------
line 175: * The reason is that if a user would re-grant a privilege that he
line 1004: * he has that, he could become that role anyway via SET ROLE, so
line 1049: * allow the ALTER; if the user lacks CREATE he'll find out when
line 1050: * he tries to create an object../src/backend/catalog/pg_shdepend.c
-----------------------------------
line 449: * Skip the owner: he has an OWNER shdep entry instead. (This is./src/backend/commands/indexcmds.c
----------------------------------
line 1358: * to specify which one he wants. (The preferred-type special case is a./src/backend/commands/user.c
-----------------------------
line 1014: * Lock the role, so nobody can add dependencies to her while we drop
line 1015: * her. We keep the lock until the end of transaction../src/backend/commands/vacuum.c
-------------------------------
line 1266: * We allow the user to vacuum a table if he is superuser, the table./src/backend/executor/execQual.c
---------------------------------
line 5483: * data will be valid, he must call ExecMaterializeSlot on the./src/backend/executor/functions.c
----------------------------------
line 1489: * to be sure that the user is returning the type he claims. There are./src/backend/libpq/auth.c
--------------------------
line 1393: * owns the tcp connection from his port "remote_port" to port./src/backend/libpq/hba.c
-------------------------
line 6: * says he comes from and choosing authentication method based on it)../src/backend/nodes/makefuncs.c
-------------------------------
line 247: * We always set these fields to 0. If the caller wants to change them he./src/backend/optimizer/plan/planner.c
--------------------------------------
line 276: * from a cursor, but it is often the case that he doesn't want 'em
line 277: * all, or would prefer a fast-start plan anyway so that he can./src/backend/parser/parse_clause.c
-----------------------------------
line 1631: * since the user didn't write them in his SELECT list.
line 2004: * used by GROUP BY, should she be working with a datatype that has
line 2523: * should she be working with a datatype that has more than one equality
line 2612: * should she be working with a datatype that has more than one equality./src/backend/port/sysv_sema.c
------------------------------
line 256: * sema key before we did. Let him have that one, loop around to try./src/backend/port/sysv_shmem.c
-------------------------------
line 534: * shmem key before we did. Let him have that one, loop around to try./src/backend/postmaster/autovacuum.c
-------------------------------------
line 1670: * Wake the launcher up so that he can launch a new worker immediately
line 2870: * All we do here is annoy the user if he got it wrong../src/backend/postmaster/pgarch.c
---------------------------------
line 333: * signal ... however, the archiver exists to protect our data, so she./src/backend/postmaster/pgstat.c
---------------------------------
line 938: * Will tell the collector about objects he can get rid of../src/backend/postmaster/postmaster.c
-------------------------------------
line 4137: * process for nearly twice AuthenticationTimeout before we kick him off../src/backend/regex/regerror.c
------------------------------
line 88: { /* unknown; tell him the number */./src/backend/storage/buffer/bufmgr.c
-------------------------------------
line 3695: * io_in_progress lock until he's done.
line 3726: * him to get unwedged../src/backend/storage/buffer/freelist.c
---------------------------------------
line 599: * buffer with the normal allocation strategy. He will then fill this
line 629: * strategy. He'll then replace this ring element via AddBufferToRing../src/backend/storage/ipc/sinvaladt.c
-------------------------------------
line 680: * him into reset state and then ignore until he catches up.
line 685: /* no point in signaling him ... */./src/backend/storage/lmgr/lock.c
---------------------------------
line 1469: * some waiter, who could now be awakened because he doesn't conflict with
line 1470: * his own locks../src/backend/storage/lmgr/proc.c
---------------------------------
line 149: * than his kernel will support, he'll find out sooner rather than later.
line 1063: /* Must he wait for me? */
line 1066: /* Must I wait for him ? */
line 1092: /* Break out of loop to put myself before him */
line 1599: * Cannot wake this guy. Remember his request for later checks../src/backend/tcop/pquery.c
---------------------------
line 500: * Fire her up according to the strategy./src/backend/utils/adt/acl.c
-----------------------------
line 819: * options. This is because his grant options come "from the system" and
line 820: * not from his own efforts. (The SQL spec says that the owner's rights
line 822: * owner's ordinary privileges are self-granted; this lets him revoke
line 4939: * FROM carol". If he creates an expression index calling that./src/backend/utils/adt/ruleutils.c
-----------------------------------
line 2080: * shouldn't use a short delimiter that he might easily create a conflict./src/backend/utils/cache/plancache.c
-------------------------------------
line 1313: /* OK, let the caller keep the plan where he wishes */./src/backend/utils/fmgr/fmgr.c
-------------------------------
line 2484: * calls to validators that he could not achieve with CREATE FUNCTION or by./src/bin/pg_dump/pg_backup_directory.c
---------------------------------------
line 47: * Our archive location. This is basically what the user specified as his./src/common/pg_lzcompress.c
----------------------------
line 160: * is omitted and only his history entry added../src/include/c.h
-----------------
line 868: * that the pointer is suitably aligned (typically, because he just got it./src/include/nodes/primnodes.h
-------------------------------
line 1329: * If he writes NATURAL then parse analysis generates the equivalent USING()
line 1331: * If he writes USING() then "quals" is filled with equality comparisons.
line 1332: * If he writes ON() then only "quals" is set. Note that NATURAL/USING./src/interfaces/libpq/fe-lobj.c
--------------------------------
line 165: * function being available, he could have called lo_truncate64 for./src/interfaces/libpq/fe-secure-openssl.c
------------------------------------------
line 750: * If the caller has told us (through PQinitOpenSSL) that he's taking care./src/nls-global.mk
-------------------
line 30: # If user specified the languages he wants in --enable-nls=LANGUAGES,./src/test/regress/expected/dependency.out
------------------------------------------
line 26: -- now we are OK to drop him./src/test/regress/sql/dependency.sql
-------------------------------------
line 27: -- now we are OK to drop him./src/tools/msvc/README
-----------------------
line 89: (i. e. path to bison and flex). In addition his config.pl file is merged into
My apologies. I'd already fixed a few, so my script no longer picked them up. They are:
diff --git a/configure b/configure
index a45be67..e67f045 100755
--- a/configure
+++ b/configure
@@ -5817,7 +5817,7 @@ fi
# There are at least three UUID libraries in common use: the FreeBSD/NetBSD
# library, the e2fsprogs libuuid (now part of util-linux-ng), and the OSSP
# UUID library. More than one of these might be present on a given platform,
-# so we make the user say which one she wants.
+# so we make the user say which one is wanted.
#diff --git a/contrib/postgres_fdw/connection.c b/contrib/postgres_fdw/connection.c
index 189f290..b690d68 100644
--- a/contrib/postgres_fdw/connection.c
+++ b/contrib/postgres_fdw/connection.c
@@ -242,7 +242,7 @@ connect_pg_server(ForeignServer *server, UserMapping *user) /*
* Check that non-superuser has used password to establish connection;
- * otherwise, he's piggybacking on the postgres server's user
+ * otherwise, the user is piggybacking on the postgres server's user
* identity. See also dblink_security_check() in contrib/dblink.
*/
if (!superuser() && !PQconnectionUsedPassword(conn))
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index e446cc5..b4d801a 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -3447,7 +3447,7 @@ foreign_join_ok(PlannerInfo *root, RelOptInfo *joinrel, JoinType jointype, /*
* If user is willing to estimate cost for a scan of either of the joining
- * relations using EXPLAIN, he intends to estimate scans on that relation
+ * relations using EXPLAIN, user intends to estimate scans on that relation
* more accurately. Then, it makes sense to estimate the cost the join
* with that relation more accurately using EXPLAIN.
*/--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
WIP patch to comments and documentation. Note that I ignored the release notes,
as I don't know if it is appropriate to change those retrospectively. A few of the
changes make the prose worse and will likely be rejected, but I included the best
change that came to mind as a starting point for conversation; perhaps somebody
will reply with improvements for v2.
Attachments:
v1.patchapplication/octet-stream; name=v1.patchDownload
diff --git a/configure b/configure
index a45be67..e67f045 100755
--- a/configure
+++ b/configure
@@ -5817,7 +5817,7 @@ fi
# There are at least three UUID libraries in common use: the FreeBSD/NetBSD
# library, the e2fsprogs libuuid (now part of util-linux-ng), and the OSSP
# UUID library. More than one of these might be present on a given platform,
-# so we make the user say which one she wants.
+# so we make the user say which one is wanted.
#
diff --git a/configure.in b/configure.in
index c298926..6251a06 100644
--- a/configure.in
+++ b/configure.in
@@ -748,7 +748,7 @@ PGAC_ARG_BOOL(with, libedit-preferred, no,
# There are at least three UUID libraries in common use: the FreeBSD/NetBSD
# library, the e2fsprogs libuuid (now part of util-linux-ng), and the OSSP
# UUID library. More than one of these might be present on a given platform,
-# so we make the user say which one she wants.
+# so we make the user say which one is wanted.
#
PGAC_ARG_REQ(with, uuid, [LIB], [build contrib/uuid-ossp using LIB (bsd,e2fs,ossp)])
if test x"$with_uuid" = x"" ; then
diff --git a/contrib/postgres_fdw/connection.c b/contrib/postgres_fdw/connection.c
index 189f290..b690d68 100644
--- a/contrib/postgres_fdw/connection.c
+++ b/contrib/postgres_fdw/connection.c
@@ -242,7 +242,7 @@ connect_pg_server(ForeignServer *server, UserMapping *user)
/*
* Check that non-superuser has used password to establish connection;
- * otherwise, he's piggybacking on the postgres server's user
+ * otherwise, the user is piggybacking on the postgres server's user
* identity. See also dblink_security_check() in contrib/dblink.
*/
if (!superuser() && !PQconnectionUsedPassword(conn))
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index e446cc5..b4d801a 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -3447,7 +3447,7 @@ foreign_join_ok(PlannerInfo *root, RelOptInfo *joinrel, JoinType jointype,
/*
* If user is willing to estimate cost for a scan of either of the joining
- * relations using EXPLAIN, he intends to estimate scans on that relation
+ * relations using EXPLAIN, user intends to estimate scans on that relation
* more accurately. Then, it makes sense to estimate the cost the join
* with that relation more accurately using EXPLAIN.
*/
diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README
index 0a7da89..3ef77bd 100644
--- a/src/backend/access/hash/README
+++ b/src/backend/access/hash/README
@@ -443,7 +443,7 @@ We have to do it this way because we must clear the bitmap bit before
changing the first-free-bit field (hashm_firstfree). It is possible that
we set first-free-bit too small (because someone has already reused the
page we just freed), but that is okay; the only cost is the next overflow
-page acquirer will scan more bitmap bits than he needs to. What must be
+page acquirer will scan more bitmap bits than necessary. What must be
avoided is having first-free-bit greater than the actual first free bit,
because then that free page would never be found by searchers.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 34ba385..e58d072 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -5271,8 +5271,8 @@ l5:
else if (old_infomask & HEAP_XMAX_COMMITTED)
{
/*
- * It's a committed update, so we need to preserve him as updater of
- * the tuple.
+ * It's a committed update, so we need to preserve the old updater as
+ * updater of the tuple.
*/
MultiXactStatus status;
MultiXactStatus new_status;
@@ -5378,8 +5378,8 @@ l5:
TransactionIdDidCommit(xmax))
{
/*
- * It's a committed update, so we gotta preserve him as updater of the
- * tuple.
+ * It's a committed update, so we gotta preserve the old updater as
+ * updater of the tuple.
*/
MultiXactStatus status;
MultiXactStatus new_status;
@@ -6554,7 +6554,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
* TransactionId read/write is assumed atomic anyway. However there is a race
* condition: someone who just fetched an old XID that we overwrite here could
* conceivably not finish checking the XID against pg_clog before we finish
- * the VACUUM and perhaps truncate off the part of pg_clog he needs. Getting
+ * the VACUUM and perhaps truncate off the needed part of pg_clog. Getting
* exclusive lock ensures no other backend is in process of checking the
* tuple status. Also, getting exclusive lock makes it safe to adjust the
* infomask bits.
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 65c941d..94cd259 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -45,7 +45,7 @@
*
* The intent is that an AM implementor will define a beginscan routine
* that calls RelationGetIndexScan, to fill in the scan, and then does
- * whatever kind of locking he wants.
+ * whatever kind of locking is desired.
*
* At the end of a scan, the AM's endscan routine undoes the locking,
* but does *not* call IndexScanEnd --- the higher-level index_endscan
diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README
index 07efebc..31195f6 100644
--- a/src/backend/access/transam/README
+++ b/src/backend/access/transam/README
@@ -104,8 +104,8 @@ situations:
------ ------
1) user types BEGIN 1) user types BEGIN
2) user does something 2) user does something
-3) user does not like what 3) system aborts for some reason
- she sees and types ABORT (syntax error, etc)
+3) user does not like the 3) system aborts for some reason
+ result and types ABORT (syntax error, etc)
In case 1, we want to abort the transaction and return to the default state.
In case 2, there may be more commands coming our way which are part of the
diff --git a/src/backend/access/transam/twophase.c b/src/backend/access/transam/twophase.c
index e7234c8..65e5765 100644
--- a/src/backend/access/transam/twophase.c
+++ b/src/backend/access/transam/twophase.c
@@ -621,7 +621,7 @@ RemoveGXact(GlobalTransaction gxact)
* structures, to minimize the time we need to hold the TwoPhaseStateLock.
*
* WARNING -- we return even those transactions that are not fully prepared
- * yet. The caller should filter them out if he doesn't want them.
+ * yet. The caller should filter them out if they are not wanted.
*
* The returned array is palloc'd.
*/
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 8a2cd45..05dcae0 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -3001,8 +3001,8 @@ AbortCurrentTransaction(void)
/*
* If we are in TBLOCK_BEGIN it means something screwed up right
* after reading "BEGIN TRANSACTION". We assume that the user
- * will interpret the error as meaning the BEGIN failed to get him
- * into a transaction block, so we should abort and return to idle
+ * will interpret the error as meaning the BEGIN failed to start
+ * a transaction block, so we should abort and return to idle
* state.
*/
case TBLOCK_BEGIN:
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f70bb49..232b984 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -8383,7 +8383,7 @@ CreateCheckPoint(int flags)
* its commit record into XLOG just before the REDO point, then a crash
* restart from the REDO point would not replay that record, which means
* that our flushing had better include the xact's update of pg_clog. So
- * we wait till he's out of his commit critical section before proceeding.
+ * we wait till it's out of its commit critical section before proceeding.
* See notes in RecordTransactionCommit().
*
* Because we've already released the insertion locks, this test is a bit
@@ -8396,8 +8396,8 @@ CreateCheckPoint(int flags)
* minimizing lock contention.)
*
* A transaction that has not yet set delayChkpt when we look cannot be at
- * risk, since he's not inserted his commit record yet; and one that's
- * already cleared it is not at risk either, since he's done fixing clog
+ * risk, since it's not inserted its commit record yet; and one that's
+ * already cleared it is not at risk either, since it's done fixing clog
* and we will correctly flush the update below. So we cannot miss any
* xacts we need to wait for.
*/
@@ -10495,8 +10495,8 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
* needs to be transported via streaming replication (hopefully with
* wal_keep_segments set high enough), or some more exotic mechanism like
* polling and copying files from pg_xlog with script. We have no
- * knowledge of those mechanisms, so it's up to the user to ensure that he
- * gets all the required WAL.
+ * knowledge of those mechanisms, so it's up to the user to ensure that
+ * all the required WAL is fetched.
*
* We wait until both the last WAL file filled during backup and the
* history file have been archived, and assume that the alphabetic sorting
@@ -10504,9 +10504,9 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
* archived as well.
*
* We wait forever, since archive_command is supposed to work and we
- * assume the admin wanted his backup to work completely. If you don't
- * wish to wait, you can set statement_timeout. Also, some notices are
- * issued to clue in anyone who might be doing this interactively.
+ * assume the admin wanted a complete backup. If you don't wish to wait,
+ * you can set statement_timeout. Also, some notices are issued to clue
+ * in anyone who might be doing this interactively.
*/
if (waitforarchive && XLogArchivingActive())
{
diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
index 0f3bc07..90013c3 100644
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -172,9 +172,9 @@ merge_acl_with_grant(Acl *old_acl, bool is_grant,
/*
* Grant options can only be granted to individual roles, not PUBLIC.
- * The reason is that if a user would re-grant a privilege that he
- * held through PUBLIC, and later the user is removed, the situation
- * is impossible to clean up.
+ * The reason is that if users can re-grant privileges that they only
+ * hold through public, there is no way to clean up any such grant after
+ * the granting user is removed.
*/
if (is_grant && grant_option && aclitem.ai_grantee == ACL_ID_PUBLIC)
ereport(ERROR,
@@ -1000,10 +1000,10 @@ ExecAlterDefaultPrivilegesStmt(AlterDefaultPrivilegesStmt *stmt)
iacls.roleid = get_rolespec_oid((Node *) rolespec, false);
/*
- * We insist that calling user be a member of each target role. If
- * he has that, he could become that role anyway via SET ROLE, so
- * FOR ROLE is just a syntactic convenience and doesn't give any
- * special privileges.
+ * We insist that calling user be a member of each target role.
+ * Since any user who is a member of a role can become that role
+ * via SET ROLE, we do not here give away any special privileges.
+ * FOR ROLE is just a syntactic convenience.
*/
check_is_member_of_role(GetUserId(), iacls.roleid);
@@ -1046,8 +1046,8 @@ SetDefaultACLsInSchemas(InternalDefaultACL *iacls, List *nspnames)
* and it also caused certain database states to not be
* dumpable/restorable, since revoking CREATE doesn't cause
* default privileges for the schema to go away. So now, we just
- * allow the ALTER; if the user lacks CREATE he'll find out when
- * he tries to create an object.
+ * allow the ALTER; users who lack CREATE will find out when they
+ * try to create an object.
*/
SetDefaultACL(iacls);
diff --git a/src/backend/catalog/pg_shdepend.c b/src/backend/catalog/pg_shdepend.c
index 65ecc45..8ac45da 100644
--- a/src/backend/catalog/pg_shdepend.c
+++ b/src/backend/catalog/pg_shdepend.c
@@ -446,7 +446,7 @@ updateAclDependencies(Oid classId, Oid objectId, int32 objsubId,
Oid roleid = newmembers[i];
/*
- * Skip the owner: he has an OWNER shdep entry instead. (This is
+ * Skip the owner, who has an OWNER shdep entry instead. (This is
* not just a space optimization; it makes ALTER OWNER easier. See
* notes in changeDependencyOnOwner.)
*/
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 13b04e6..19bd000 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -1355,7 +1355,7 @@ GetDefaultOpClass(Oid type_id, Oid am_id)
*
* We could find more than one binary-compatible match. If just one is
* for a preferred type, use that one; otherwise we fail, forcing the user
- * to specify which one he wants. (The preferred-type special case is a
+ * to specify which one is wanted. (The preferred-type special case is a
* kluge for varchar: it's binary-compatible to both text and bpchar, so
* we need a tiebreaker.) If we find more than one exact match, then
* someone put bogus entries in pg_opclass.
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 4baeaa2..56d8ce3 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -1011,8 +1011,8 @@ DropRole(DropRoleStmt *stmt)
InvokeObjectDropHook(AuthIdRelationId, roleid, 0);
/*
- * Lock the role, so nobody can add dependencies to her while we drop
- * her. We keep the lock until the end of transaction.
+ * Lock the role, so nobody can add dependencies to it while we drop
+ * it. We keep the lock until the end of transaction.
*/
LockSharedObject(AuthIdRelationId, roleid, 0, AccessExclusiveLock);
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 4cb4acf..6a65d83 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1263,9 +1263,10 @@ vacuum_rel(Oid relid, RangeVar *relation, int options, VacuumParams *params)
/*
* Check permissions.
*
- * We allow the user to vacuum a table if he is superuser, the table
- * owner, or the database owner (but in the latter case, only if it's not
- * a shared relation). pg_class_ownercheck includes the superuser case.
+ * We unconditionally allow vacuums of a table by superusers and the
+ * table's owner. Tables within a database can also be vacuumed
+ * by the database owner, but only if the table is not a shared
+ * relation. pg_class_ownercheck includes the superuser case.
*
* Note we choose to treat permissions failure as a WARNING and keep
* trying to vacuum the rest of the DB --- is this appropriate?
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index 778b6c1..658c3d6 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -5479,9 +5479,8 @@ ExecTargetList(List *targetlist,
* Note: the result is always a virtual tuple; therefore it
* may reference the contents of the exprContext's scan tuples
* and/or temporary results constructed in the exprContext.
- * If the caller wishes the result to be valid longer than that
- * data will be valid, he must call ExecMaterializeSlot on the
- * result slot.
+ * Results are only valid as long as the referenced data unless
+ * ExecMaterializeSlot is called on the result slot.
*/
TupleTableSlot *
ExecProject(ProjectionInfo *projInfo, ExprDoneCond *isDone)
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index 6e14c9d..921188a 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -1486,7 +1486,7 @@ ShutdownSQLFunction(Datum arg)
*
* The return value of a sql function is the value returned by the last
* canSetTag query in the function. We do some ad-hoc type checking here
- * to be sure that the user is returning the type he claims. There are
+ * to be sure that the user is returning the type claimed. There are
* also a couple of strange-looking features to assist callers in dealing
* with allowed special cases, such as binary-compatible result types.
*
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 7f1ae8c..dc07cf8 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1390,7 +1390,7 @@ interpret_ident_response(const char *ident_response,
/*
* Talk to the ident server on host "remote_ip_addr" and find out who
- * owns the tcp connection from his port "remote_port" to port
+ * owns the tcp connection from port "remote_port" on that host to port
* "local_port_addr" on host "local_ip_addr". Return the user name the
* ident server gives as "*ident_user".
*
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 28f9fb5..d3ce966 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -3,7 +3,8 @@
* hba.c
* Routines to handle host based authentication (that's the scheme
* wherein you authenticate a user by seeing what IP address the system
- * says he comes from and choosing authentication method based on it).
+ * says the connection comes from and choosing authentication method
+ * based on it).
*
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
diff --git a/src/backend/nodes/makefuncs.c b/src/backend/nodes/makefuncs.c
index f625c32..37885e0 100644
--- a/src/backend/nodes/makefuncs.c
+++ b/src/backend/nodes/makefuncs.c
@@ -244,7 +244,7 @@ makeTargetEntry(Expr *expr,
tle->resname = resname;
/*
- * We always set these fields to 0. If the caller wants to change them he
+ * We always set these fields to 0. Any caller who wants to change them
* must do so explicitly. Few callers do that, so omitting these
* arguments reduces the chance of error.
*/
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index fc0a2d8..1fc3c19 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -273,10 +273,10 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
{
/*
* We have no real idea how many tuples the user will ultimately FETCH
- * from a cursor, but it is often the case that he doesn't want 'em
- * all, or would prefer a fast-start plan anyway so that he can
- * process some of the tuples sooner. Use a GUC parameter to decide
- * what fraction to optimize for.
+ * from a cursor, but it is frequently fewer than all of them. A
+ * fast-start plan may be prefered anyway so that processing of tuples
+ * can begin sooner. Use a GUC parameter to decide what fraction to
+ * optimize for.
*/
tuple_fraction = cursor_tuple_fraction;
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 4d9febe..b8563e8 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -1628,7 +1628,7 @@ findTargetlistEntrySQL92(ParseState *pstate, Node *node, List **tlist,
* we may as well accept this common extension.
*
* Note that pre-existing resjunk targets must not be used in either case,
- * since the user didn't write them in his SELECT list.
+ * since the user didn't write them in the SELECT list.
*
* If neither special case applies, fall through to treat the item as
* an expression per SQL99.
@@ -2001,8 +2001,8 @@ transformGroupClauseExpr(List **flatresult, Bitmapset *seen_local,
* by the ORDER BY. There are two reasons to do this: it improves the
* odds that we can implement both GROUP BY and ORDER BY with a single
* sort step, and it allows the user to choose the equality semantics
- * used by GROUP BY, should she be working with a datatype that has
- * more than one equality operator.
+ * used by GROUP BY, when working with a datatype that has more than
+ * one equality operator.
*
* If we're in a grouping set, though, we force our requested ordering
* to be NULLS LAST, because if we have any hope of using a sorted agg
@@ -2520,8 +2520,7 @@ transformWindowDefinitions(ParseState *pstate,
* As with GROUP BY, we absorb the sorting semantics of ORDER BY as much as
* possible into the distinctClause. This avoids a possible need to re-sort,
* and allows the user to choose the equality semantics used by DISTINCT,
- * should she be working with a datatype that has more than one equality
- * operator.
+ * when working with a datatype that has more than one equality operator.
*
* is_agg is true if we are transforming an aggregate(DISTINCT ...)
* function call. This does not affect any behavior, only the phrasing
@@ -2609,8 +2608,7 @@ transformDistinctClause(ParseState *pstate,
* As with GROUP BY, we absorb the sorting semantics of ORDER BY as much as
* possible into the distinctClause. This avoids a possible need to re-sort,
* and allows the user to choose the equality semantics used by DISTINCT,
- * should she be working with a datatype that has more than one equality
- * operator.
+ * when working with a datatype that has more than one equality operator.
*/
List *
transformDistinctOnClause(ParseState *pstate, List *distinctlist,
diff --git a/src/backend/port/sysv_sema.c b/src/backend/port/sysv_sema.c
index f6f1516..a8111e9 100644
--- a/src/backend/port/sysv_sema.c
+++ b/src/backend/port/sysv_sema.c
@@ -253,8 +253,8 @@ IpcSemaphoreCreate(int numSems)
/*
* Can only get here if some other process managed to create the same
- * sema key before we did. Let him have that one, loop around to try
- * next key.
+ * sema key before we did. Let the other process have that one, while
+ * we loop around to try next key.
*/
}
diff --git a/src/backend/port/sysv_shmem.c b/src/backend/port/sysv_shmem.c
index 6c442b9..aea1e36 100644
--- a/src/backend/port/sysv_shmem.c
+++ b/src/backend/port/sysv_shmem.c
@@ -531,8 +531,8 @@ PGSharedMemoryCreate(Size size, bool makePrivate, int port,
/*
* Can only get here if some other process managed to create the same
- * shmem key before we did. Let him have that one, loop around to try
- * next key.
+ * sema key before we did. Let the other process have that one, while
+ * we loop around to try next key.
*/
}
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index e2859df..89f6d71 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -1667,7 +1667,7 @@ FreeWorkerInfo(int code, Datum arg)
LWLockAcquire(AutovacuumLock, LW_EXCLUSIVE);
/*
- * Wake the launcher up so that he can launch a new worker immediately
+ * Wake the launcher up so that it can launch a new worker immediately
* if required. We only save the launcher's PID in local memory here;
* the actual signal will be sent when the PGPROC is recycled. Note
* that we always do this, so that the launcher can rebalance the cost
@@ -2867,7 +2867,7 @@ AutoVacuumingActive(void)
* autovac_init
* This is called at postmaster initialization.
*
- * All we do here is annoy the user if he got it wrong.
+ * All we do here is annoy the user if autovacuum is misconfigured.
*/
void
autovac_init(void)
diff --git a/src/backend/postmaster/pgarch.c b/src/backend/postmaster/pgarch.c
index 1aa6466..bdccc2b 100644
--- a/src/backend/postmaster/pgarch.c
+++ b/src/backend/postmaster/pgarch.c
@@ -330,8 +330,8 @@ pgarch_MainLoop(void)
/*
* There shouldn't be anything for the archiver to do except to wait for a
- * signal ... however, the archiver exists to protect our data, so she
- * wakes up occasionally to allow herself to be proactive.
+ * signal ... however, the archiver exists to protect our data, so it
+ * wakes up occasionally to allow itself to be proactive.
*/
do
{
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 1467355..41cdcdb 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -935,7 +935,7 @@ pgstat_send_funcstats(void)
/* ----------
* pgstat_vacuum_stat() -
*
- * Will tell the collector about objects he can get rid of.
+ * Will tell the collector about objects it can get rid of.
* ----------
*/
void
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b16fc28..506e49e 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -4134,7 +4134,8 @@ BackendInitialize(Port *port)
* Note: AuthenticationTimeout is applied here while waiting for the
* startup packet, and then again in InitPostgres for the duration of any
* authentication operations. So a hostile client could tie up the
- * process for nearly twice AuthenticationTimeout before we kick him off.
+ * process for nearly twice AuthenticationTimeout before getting kicked
+ * off by us.
*
* Note: because PostgresMain will call InitializeTimeouts again, the
* registration of STARTUP_PACKET_TIMEOUT will be lost. This is okay
diff --git a/src/backend/regex/regerror.c b/src/backend/regex/regerror.c
index f2fe696..36d897d 100644
--- a/src/backend/regex/regerror.c
+++ b/src/backend/regex/regerror.c
@@ -85,7 +85,7 @@ pg_regerror(int errcode, /* error code, or REG_ATOI or REG_ITOA */
if (r->code >= 0)
msg = r->name;
else
- { /* unknown; tell him the number */
+ { /* unknown; report the number */
sprintf(convbuf, "REG_%u", (unsigned) icode);
msg = convbuf;
}
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 6dd7c6e..070f8e4 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -3690,9 +3690,9 @@ WaitIO(BufferDesc *buf)
* The buffer is Pinned
*
* In some scenarios there are race conditions in which multiple backends
- * could attempt the same I/O operation concurrently. If someone else
- * has already started I/O on this buffer then we will block on the
- * io_in_progress lock until he's done.
+ * could attempt the same I/O operation concurrently. If some other
+ * backend process has already started I/O on this buffer then we will
+ * block on the io_in_progress lock until that other process is done.
*
* Input operations are only attempted on buffers that are not BM_VALID,
* and output operations only on buffers that are BM_VALID and BM_DIRTY,
@@ -3723,7 +3723,7 @@ StartBufferIO(BufferDesc *buf, bool forInput)
* The only way BM_IO_IN_PROGRESS could be set when the io_in_progress
* lock isn't held is if the process doing the I/O is recovering from
* an error (see AbortBufferIO). If that's the case, we must wait for
- * him to get unwedged.
+ * that other process to get unwedged.
*/
UnlockBufHdr(buf);
LWLockRelease(BufferDescriptorGetIOLock(buf));
diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c
index 551d152..081975b 100644
--- a/src/backend/storage/buffer/freelist.c
+++ b/src/backend/storage/buffer/freelist.c
@@ -596,7 +596,7 @@ GetBufferFromRing(BufferAccessStrategy strategy)
/*
* If the slot hasn't been filled yet, tell the caller to allocate a new
- * buffer with the normal allocation strategy. He will then fill this
+ * buffer with the normal allocation strategy. Caller shall then fill this
* slot by calling AddBufferToRing with the new buffer.
*/
bufnum = strategy->buffers[strategy->current];
@@ -626,7 +626,8 @@ GetBufferFromRing(BufferAccessStrategy strategy)
/*
* Tell caller to allocate a new buffer with the normal allocation
- * strategy. He'll then replace this ring element via AddBufferToRing.
+ * strategy. Caller shall then replace this ring element via
+ * AddBufferToRing.
*/
strategy->current_was_in_ring = false;
return NULL;
diff --git a/src/backend/storage/ipc/sinvaladt.c b/src/backend/storage/ipc/sinvaladt.c
index 44a9f2c..3917dd5 100644
--- a/src/backend/storage/ipc/sinvaladt.c
+++ b/src/backend/storage/ipc/sinvaladt.c
@@ -677,12 +677,12 @@ SICleanupQueue(bool callerHasWriteLock, int minFree)
/*
* If we must free some space and this backend is preventing it, force
- * him into reset state and then ignore until he catches up.
+ * this backend into reset state and then ignore it until it catches up.
*/
if (n < lowbound)
{
stateP->resetState = true;
- /* no point in signaling him ... */
+ /* no point in signaling it before it catches up ... */
continue;
}
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index b30b7b1..22d9333 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1466,8 +1466,8 @@ UnGrantLock(LOCK *lock, LOCKMODE lockmode,
* conflict made them wait must still exist. NOTE: before MVCC, we could
* skip wakeup if lock->granted[lockmode] was still positive. But that's
* not true anymore, because the remaining granted locks might belong to
- * some waiter, who could now be awakened because he doesn't conflict with
- * his own locks.
+ * one or more waiters, who could now be awakened because they don't
+ * conflict with their own locks.
*/
if (lockMethodTable->conflictTab[lockmode] & lock->waitMask)
wakeupNeeded = true;
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index a66e07b..e892ce0 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -146,7 +146,8 @@ ProcGlobalSemas(void)
* So, now we grab enough semaphores to support the desired max number
* of backends immediately at initialization --- if the sysadmin has set
* MaxConnections, max_worker_processes, or autovacuum_max_workers higher
- * than his kernel will support, he'll find out sooner rather than later.
+ * than his kernel will support, it will be obvious sooner rather than
+ * later.
*
* Another reason for creating semaphores here is that the semaphore
* implementation typically requires us to create semaphores in the
@@ -1060,10 +1061,10 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
proc = (PGPROC *) proc->links.next;
continue;
}
- /* Must he wait for me? */
+ /* Must this waiter wait for me? */
if (lockMethodTable->conflictTab[proc->waitLockMode] & myHeldLocks)
{
- /* Must I wait for him ? */
+ /* Must I wait for this waiter ? */
if (lockMethodTable->conflictTab[lockmode] & proc->heldLocks)
{
/*
@@ -1089,7 +1090,7 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
GrantAwaitedLock();
return STATUS_OK;
}
- /* Break out of loop to put myself before him */
+ /* Break out of loop to put myself before this waiter */
break;
}
/* Nope, so advance to next waiter */
@@ -1596,7 +1597,7 @@ ProcLockWakeup(LockMethod lockMethodTable, LOCK *lock)
else
{
/*
- * Cannot wake this guy. Remember his request for later checks.
+ * Cannot wake this process. Remember its request for later checks.
*/
aheadRequests |= LOCKBIT_ON(lockmode);
proc = (PGPROC *) proc->links.next;
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index fcdc4c3..77baa49 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -497,7 +497,7 @@ PortalStart(Portal portal, ParamListInfo params,
portal->strategy = ChoosePortalStrategy(portal->stmts);
/*
- * Fire her up according to the strategy
+ * Fire it up according to the strategy
*/
switch (portal->strategy)
{
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 63fbce0..7492fcd 100644
--- a/src/backend/utils/adt/acl.c
+++ b/src/backend/utils/adt/acl.c
@@ -816,10 +816,10 @@ acldefault(GrantObjectType objtype, Oid ownerId)
/*
* Note that the owner's entry shows all ordinary privileges but no grant
- * options. This is because his grant options come "from the system" and
- * not from his own efforts. (The SQL spec says that the owner's rights
+ * options. This is because grant options come "from the system" and
+ * not from one's own efforts. (The SQL spec says that the owner's rights
* come from a "_SYSTEM" authid.) However, we do consider that the
- * owner's ordinary privileges are self-granted; this lets him revoke
+ * owner's ordinary privileges are self-granted; this lets owners revoke
* them. We implement the owner's grant options without any explicit
* "_SYSTEM"-like ACL entry, by internally special-casing the owner
* wherever we are testing grant options.
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 490a090..702d85e 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -2077,8 +2077,8 @@ pg_get_functiondef(PG_FUNCTION_ARGS)
* We always use dollar quoting. Figure out a suitable delimiter.
*
* Since the user is likely to be editing the function body string, we
- * shouldn't use a short delimiter that he might easily create a conflict
- * with. Hence prefer "$function$", but extend if needed.
+ * shouldn't use a short delimiter that might easily create a conflict.
+ * Hence prefer "$function$", but extend if needed.
*/
initStringInfo(&dq);
appendStringInfoString(&dq, "$function");
diff --git a/src/backend/utils/cache/plancache.c b/src/backend/utils/cache/plancache.c
index a93825d..5d23e36 100644
--- a/src/backend/utils/cache/plancache.c
+++ b/src/backend/utils/cache/plancache.c
@@ -1310,7 +1310,7 @@ CachedPlanSetParentContext(CachedPlanSource *plansource,
if (plansource->is_oneshot)
elog(ERROR, "cannot move a one-shot cached plan to another context");
- /* OK, let the caller keep the plan where he wishes */
+ /* OK, let the caller keep the plan in the caller supplied context */
MemoryContextSetParent(plansource->context, newcontext);
/*
diff --git a/src/backend/utils/fmgr/fmgr.c b/src/backend/utils/fmgr/fmgr.c
index ad8541c..5af522b 100644
--- a/src/backend/utils/fmgr/fmgr.c
+++ b/src/backend/utils/fmgr/fmgr.c
@@ -2480,8 +2480,8 @@ get_fn_expr_variadic(FmgrInfo *flinfo)
* Verify that a validator is actually associated with the language of a
* particular function and that the user has access to both the language and
* the function. All validators should call this before doing anything
- * substantial. Doing so ensures a user cannot achieve anything with explicit
- * calls to validators that he could not achieve with CREATE FUNCTION or by
+ * substantial. Doing so ensures users cannot achieve anything with explicit
+ * calls to validators that could not be achieved with CREATE FUNCTION or by
* simply calling an existing function.
*
* When this function returns false, callers should skip all validation work
diff --git a/src/bin/pg_dump/pg_backup_directory.c b/src/bin/pg_dump/pg_backup_directory.c
index 1d7b0cc..3c5982a 100644
--- a/src/bin/pg_dump/pg_backup_directory.c
+++ b/src/bin/pg_dump/pg_backup_directory.c
@@ -44,7 +44,7 @@
typedef struct
{
/*
- * Our archive location. This is basically what the user specified as his
+ * Our archive location. This is basically what the user specified as the
* backup file but of course here it is a directory.
*/
char *directory;
diff --git a/src/common/pg_lzcompress.c b/src/common/pg_lzcompress.c
index 985841d..70b86c3 100644
--- a/src/common/pg_lzcompress.c
+++ b/src/common/pg_lzcompress.c
@@ -157,7 +157,7 @@
* amount of copy information to code into a tag. If so, a tag
* is omitted and all the input bytes covered by that are just
* scanned for the history add's, otherwise a literal character
- * is omitted and only his history entry added.
+ * is omitted and only its history entry added.
*
* Acknowledgements:
*
diff --git a/src/include/c.h b/src/include/c.h
index 7c57430..ecf9dd6 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -865,8 +865,8 @@ typedef NameData *Name;
/*
* MemSetAligned is the same as MemSet except it omits the test to see if
* "start" is word-aligned. This is okay to use if the caller knows a-priori
- * that the pointer is suitably aligned (typically, because he just got it
- * from palloc(), which always delivers a max-aligned pointer).
+ * that the pointer is suitably aligned (typically, because it came from
+ * palloc(), which always delivers a max-aligned pointer).
*/
#define MemSetAligned(start, val, len) \
do \
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index f942378..0097850 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -1324,13 +1324,13 @@ typedef struct RangeTblRef
/*----------
* JoinExpr - for SQL JOIN expressions
*
- * isNatural, usingClause, and quals are interdependent. The user can write
- * only one of NATURAL, USING(), or ON() (this is enforced by the grammar).
- * If he writes NATURAL then parse analysis generates the equivalent USING()
- * list, and from that fills in "quals" with the right equality comparisons.
- * If he writes USING() then "quals" is filled with equality comparisons.
- * If he writes ON() then only "quals" is set. Note that NATURAL/USING
- * are not equivalent to ON() since they also affect the output column list.
+ * isNatural, usingClause, and quals are interdependent. The grammar allows
+ * only one of NATURAL, USING(), or ON(). For NATURAL, parse analysis
+ * generates the equivalent USING() list, and from that fills in "quals"
+ * with the right equality comparisons. For USING(), parse analysis fills
+ * in "quals" with equality comparisons. For ON(), only "quals" is set.
+ * Note that NATURAL/USING are not equivalent to ON() since they also affect
+ * the output column list.
*
* alias is an Alias node representing the AS alias-clause attached to the
* join expression, or NULL if no clause. NB: presence or absence of the
diff --git a/src/interfaces/libpq/fe-lobj.c b/src/interfaces/libpq/fe-lobj.c
index 3b08768..5289f2c 100644
--- a/src/interfaces/libpq/fe-lobj.c
+++ b/src/interfaces/libpq/fe-lobj.c
@@ -161,9 +161,8 @@ lo_truncate(PGconn *conn, int fd, size_t len)
* as taking size_t ... but the underlying backend function only accepts a
* signed int32 length. So throw error if the given value overflows
* int32. (A possible alternative is to automatically redirect the call
- * to lo_truncate64; but if the caller wanted to rely on that backend
- * function being available, he could have called lo_truncate64 for
- * himself.)
+ * to lo_truncate64; but callers wanting to rely on that backend
+ * function being available can call lo_truncate64 themselves.)
*/
if (len > (size_t) INT_MAX)
{
diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/libpq/fe-secure-openssl.c
index 133546b..339280f 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -747,9 +747,9 @@ pq_lockingcallback(int mode, int n, const char *file, int line)
* In threadsafe mode, this includes setting up libcrypto callback functions
* to do thread locking.
*
- * If the caller has told us (through PQinitOpenSSL) that he's taking care
- * of libcrypto, we expect that callbacks are already set, and won't try to
- * override it.
+ * For callers who have told us (through PQinitOpenSSL) that they are taking
+ * care of libcrypto, we expect that callbacks are already set, and won't try
+ * to override it.
*
* The conn parameter is only used to be able to pass back an error
* message - no connection-local setup is made here.
diff --git a/src/nls-global.mk b/src/nls-global.mk
index b90a3f3..9bcba2e 100644
--- a/src/nls-global.mk
+++ b/src/nls-global.mk
@@ -27,7 +27,7 @@
# existence checked by Makefile.global; otherwise we won't get here
include $(srcdir)/nls.mk
-# If user specified the languages he wants in --enable-nls=LANGUAGES,
+# If user specified the desired languages in --enable-nls=LANGUAGES,
# filter out the rest. Else use all available ones.
ifdef WANTED_LANGUAGES
LANGUAGES = $(filter $(WANTED_LANGUAGES), $(AVAIL_LANGUAGES))
diff --git a/src/test/regress/expected/dependency.out b/src/test/regress/expected/dependency.out
index caba88f..62c1787 100644
--- a/src/test/regress/expected/dependency.out
+++ b/src/test/regress/expected/dependency.out
@@ -23,7 +23,7 @@ REVOKE SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES ON deptest FROM regr
DROP USER regression_user;
ERROR: role "regression_user" cannot be dropped because some objects depend on it
DETAIL: privileges for table deptest
--- now we are OK to drop him
+-- now we are OK to drop the user
REVOKE TRIGGER ON deptest FROM regression_user;
DROP USER regression_user;
-- we are OK too if we drop the privileges all at once
diff --git a/src/test/regress/sql/dependency.sql b/src/test/regress/sql/dependency.sql
index 599a359..5dfe5a3 100644
--- a/src/test/regress/sql/dependency.sql
+++ b/src/test/regress/sql/dependency.sql
@@ -24,7 +24,7 @@ DROP GROUP regression_group;
REVOKE SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES ON deptest FROM regression_user;
DROP USER regression_user;
--- now we are OK to drop him
+-- now we are OK to drop the user
REVOKE TRIGGER ON deptest FROM regression_user;
DROP USER regression_user;
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index b61ddb8..04e1d66 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -86,8 +86,8 @@ Description of the internals of the Visual Studio build process
By typing 'build' the user starts the build.bat wrapper which simply passes
it's arguments to build.pl.
In build.pl the user's buildenv.pl is used to set up the build environment
-(i. e. path to bison and flex). In addition his config.pl file is merged into
-config_default.pl to create the configuration arguments.
+(i. e. path to bison and flex). In addition the user's config.pl file is
+merged into config_default.pl to create the configuration arguments.
These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
On Thu, Mar 17, 2016 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Chapman Flack <chap@anastigmatix.net> writes:
On 03/17/16 17:29, Kevin Grittner wrote:
A grep with a quick skim of the results to exclude references to
particular people who are mentioned by name and then referred to
with a pronoun (which I assume we can leave alone), suggest there
are about 70 lines in the 1346667 line C code base that need work.Any word-smiths out there who want to volunteer to sort this out?
So that must be N affected files for some N <= 70 ...
what would you think of starting a wiki page with those N filenames
(so nobody has to repeat your grepping/skimming effort), and volunteers
can claim a file or five, marking them taken on that page, and wordsmith
away?Yeah, Kevin, could you post your results? I'd have guessed there were
more trouble spots than that. If that really is the size of the problem,
seems like we could fix all those instances in one patch and be done
with it. (At least till new ones sneak in :-()
I see others have also been scanning the sgml sources, while I was
just looking at .c and .h files. FWIW, I've attached grep results
based on what I used for my initial count, which was just scanning
for the six gender-specific pronouns that came to mind at the time
-- I probably missed some, but this should be the bulk of it I
think. This time I included a few lines around each pronoun for
context; hopefully that makes it easier for the word-smiths. I
removed results where "he" was used as a local variable name for a
HeapEntry and those places where the pronoun referred back to a
person (e.g., Knuth) who was mentioned just above.
Note that since multiple lines with gender-specific pronouns
sometimes are near each other and thus show up in the same block,
there are 59 blocks in 42 files.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
On Thu, Mar 17, 2016 at 11:41 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
Note that since multiple lines with gender-specific pronouns
sometimes are near each other and thus show up in the same block,
there are 59 blocks in 42 files.
Adding two more pronouns I noticed in a closer scan of the initial results
makes that 61 blocks in 43 files.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company