Обсуждение: 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.
Вложения
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
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
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.
"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
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.
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 documentation > > JD 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
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
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 documentation
JD
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
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
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
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
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
> 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
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
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
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
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
On Thursday, March 17, 2016, Robert Haas <robertmhaas@gmail.com> wrote:
Beyond that it's the usual bike shedding when it comes to writing...which was the original contra-vote.
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....
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.
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
settingsline3446: Once a user logs into a role, she obtains capabilities ofline 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.line2996: 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.
line494: uncooperative role member could provide most of his rights to othersline 2719: function with
forgedinput data, by installing it on a table he owns.line 5223: a database he owns, this would remove all
specialparameter settings
./doc/src/sgml/release-9.0.sgml
-------------------------------line 1220: within a command parameter might succeed in injecting his own SQLline
2382: revoke the access of others, contrary to the wishes of his grantor.line 2384: uncooperative role
membercould provide most of his rights to othersline 5089: function with forged input data, by installing it on a
tablehe owns.
./doc/src/sgml/release-9.1.sgml
-------------------------------line 1867: within a command parameter might succeed in injecting his own SQLline
3164: revoke the access of others, contrary to the wishes of his grantor.line 3166: uncooperative role
membercould provide most of his rights to othersline 6551: function with forged input data, by installing it on a
tablehe owns.
./doc/src/sgml/release-9.2.sgml
-------------------------------line 2006: within a command parameter might succeed in injecting his own SQLline
3521: revoke the access of others, contrary to the wishes of his grantor.line 3523: uncooperative role
membercould 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 SQLline
5641: revoke the access of others, contrary to the wishes of his grantor.line 5643: uncooperative role
membercould 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
updaterofline 5381: * It's a committed update, so we gotta preserve him as updater of theline 6557: * the
VACUUMand 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
failedto get him
./src/backend/access/transam/xlog.c
-----------------------------------line 8386: * we wait till he's out of his commit critical section before
proceeding.line8399: * risk, since he's not inserted his commit record yet; and one that'sline 8400: *
alreadycleared 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
heline1004: * he has that, he could become that role anyway via SET ROLE, soline 1049:
* allow the ALTER; if the user lacks CREATE he'll find out whenline 1050: * he tries to
createan 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
dropline1015: * 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 hasline 2523: * should she be working with a
datatypethat has more than one equalityline 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
totry
./src/backend/postmaster/autovacuum.c
-------------------------------------line 1670: * Wake the launcher up so that he can launch a new worker
immediatelyline2870: * 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
himoff.
./src/backend/regex/regerror.c
------------------------------ line 88: { /* unknown; tell
himthe number */
./src/backend/storage/buffer/bufmgr.c
-------------------------------------line 3695: * io_in_progress lock until he's done.line 3726: * him to
getunwedged.
./src/backend/storage/buffer/freelist.c
--------------------------------------- line 599: * buffer with the normal allocation strategy. He will then fill
thisline 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
withline1470: * his own locks.
./src/backend/storage/lmgr/proc.c
--------------------------------- line 149: * than his kernel will support, he'll find out sooner rather than
later.line1063: /* 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
line820: * not from his own efforts. (The SQL spec says that the owner's rights line 822: * owner's ordinary
privilegesare self-granted; this lets him revokeline 4939: * FROM carol". If he creates an expression
indexcalling 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
specifiedas 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()line1331: * 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
takingcare
./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
> 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
e2fsprogslibuuid (now part of util-linux-ng), and the OSSP# UUID library. More than one of these might be present on a
givenplatform,
-# 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
thatnon-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
alsodblink_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
useris 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
makessense to estimate the cost the join * with that relation more accurately using EXPLAIN. */
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.
Вложения
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
Вложения
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