Re: [HACKERS] Make primnodes.h gender neutral

2016-03-20 Thread Mark Dilger 

> On Mar 17, 2016, at 12:31 PM, Joshua D. Drake  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.
> 
> -- 
> 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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Kevin Grittner 
On Thu, Mar 17, 2016 at 4:34 PM, David G. Johnston
 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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Kevin Grittner 
On Thu, Mar 17, 2016 at 4:11 PM, Tom Lane  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Joshua D. Drake 

On 03/17/2016 02:11 PM, Tom Lane wrote:

"Joshua D. Drake"  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Joshua D. Drake 

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  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Tom Lane 
Chapman Flack  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Tom Lane 
"Joshua D. Drake"  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Mark Dilger 
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.




v1.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Mark Dilger 

> On Mar 17, 2016, at 5:40 PM, Mark Dilger  wrote:
> 
> 
>> On Mar 17, 2016, at 5:05 PM, Peter Geoghegan  wrote:
>> 
>> On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane  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: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
>

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Peter Geoghegan 
On Thu, Mar 17, 2016 at 4:09 PM, Robert Haas  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Robert Haas 
On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Robert Haas 
On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Mark Dilger 

> On Mar 17, 2016, at 5:05 PM, Peter Geoghegan  wrote:
> 
> On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane  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: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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread David G. Johnston 
On Thursday, March 17, 2016, Robert Haas  wrote:

> On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack  > 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.

Beyond that it's the usual bike shedding when it comes to writing...which
was the original contra-vote.

David J.

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Chapman Flack 
On 03/17/16 19:09, Robert Haas wrote:
> On Thu, Mar 17, 2016 at 6:34 PM, Chapman Flack  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Alvaro Herrera 
Robert Haas wrote:
> On Thu, Mar 17, 2016 at 3:31 PM, Joshua D. Drake  
> 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 Herrerahttp://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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Chapman Flack 
On 03/17/16 17:29, Kevin Grittner wrote:
> On Thu, Mar 17, 2016 at 4:11 PM, Tom Lane  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread David G. Johnston 
On Thu, Mar 17, 2016 at 2:17 PM, Gavin Flower  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 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.

[HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Joshua D. Drake 

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.
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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Alvaro Herrera 
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  
> >>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 Herrerahttp://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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Gavin Flower 

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-19 Thread Kevin Grittner 
On Thu, Mar 17, 2016 at 11:41 PM, Kevin Grittner  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
kgrittn@Kevin-Desktop:~/pg/master$ find -type f -name '*.[hc]' | grep -v 
'/tmp_check/' | grep -v '/Debug/' | xargs egrep -i -B3 -A3 
'\b(him|her|his|hers|he|she|himself|herself)\b'
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * isNatural, usingClause, and quals are 
interdependent.  The user can write
./src/include/nodes/primnodes.h- * only one of NATURAL, USING(), or ON() (this 
is enforced by the grammar).
./src/include/nodes/primnodes.h: * If he writes NATURAL then parse analysis 
generates the equivalent USING()
./src/include/nodes/primnodes.h- * list, and from that fills in "quals" with 
the right equality comparisons.
./src/include/nodes/primnodes.h: * If he writes USING() then "quals" is filled 
with equality comparisons.
./src/include/nodes/primnodes.h: * If he writes ON() then only "quals" is set.  
Note that NATURAL/USING
./src/include/nodes/primnodes.h- * are not equivalent to ON() since they also 
affect the output column list.
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * alias is an Alias node representing the AS 
alias-clause attached to the
--
./src/include/c.h-/*
./src/include/c.h- * MemSetAligned is the same as MemSet except it omits the 
test to see if
./src/include/c.h- * "start" is word-aligned.  This is okay to use if the 
caller knows a-priori
./src/include/c.h: * that the pointer is suitably aligned (typically, because 
he just got it
./src/include/c.h- * from palloc(), which always delivers a max-aligned 
pointer).
./src/include/c.h- */
./src/include/c.h-#define MemSetAligned(start, val, len) \
--
./src/bin/pg_dump/pg_backup_directory.c-typedef struct
./src/bin/pg_dump/pg_backup_directory.c-{
./src/bin/pg_dump/pg_backup_directory.c-/*
./src/bin/pg_dump/pg_backup_directory.c: * Our archive location. This 
is basically what the user specified as his
./src/bin/pg_dump/pg_backup_directory.c- * backup file but of course 
here it is a directory.
./src/bin/pg_dump/pg_backup_directory.c- */
./src/bin/pg_dump/pg_backup_directory.c-char   *directory;
--
./src/backend/nodes/makefuncs.c-tle->resname = resname;
./src/backend/nodes/makefuncs.c-
./src/backend/nodes/makefuncs.c-/*
./src/backend/nodes/makefuncs.c: * We always set these fields to 0. If 
the caller wants to change them he
./src/backend/nodes/makefuncs.c- * must do so explicitly.  Few callers 
do that, so omitting these
./src/backend/nodes/makefuncs.c- * arguments reduces the chance of 
error.
./src/backend/nodes/makefuncs.c- */
--
./src/backend/parser/parse_clause.c- *we may as well accept this 
common extension.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * Note that pre-existing resjunk 
targets must not be used in either case,
./src/backend/parser/parse_clause.c: * since the user didn't write them in 
his SELECT list.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * If neither special case applies, 
fall through to treat the item as
./src/backend/parser/parse_clause.c- * an expression per SQL99.
--
./src/backend/parser/parse_clause.c- * by the ORDER BY.  There are 
two reasons to do this: it improves the
./src/backend/parser/parse_clause.c- * odds that we can implement 
both GROUP BY and ORDER BY with a single
./src/backend/parser/parse_clause.c- * sort step, and it allows the 
user to choose the equality semantics
./src/backend/parser/parse_clause.c: * used by GROUP BY, should she 
be working with a datatype that has
./src/backend/parser/parse_clause.c- * more than one equality 
operator.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * If we're in a grouping set, 
though, we force our requested ordering
--
./src/backend/parser/parse_clause.c- * As with GROUP BY, we absorb the sorting 
semantics of ORDER BY as much as
./src/backend/parser/parse_clause.c- * possible into the distinctClause.  This 
avoids a possible need to re-sort,
./src/backend/parser/parse_clause.c- * and allows the user to choose the 
equality semantics used by DISTINCT,
./src/backend/parser/parse_clause.c: * should she be working with a datatype 
that has more than one equality
./src/backend/parser/parse_clause.c- * operator.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * is_agg is true if we are transforming an 
aggregate(DISTINCT ...)
--

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-18 Thread Peter Geoghegan 
On Thu, Mar 17, 2016 at 4:46 PM, Tom Lane  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

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-18 Thread Kevin Grittner 
On Thu, Mar 17, 2016 at 6:07 PM, Tom Lane  wrote:
> Chapman Flack  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
kgrittn@Kevin-Desktop:~/pg/master$ find -type f -name '*.[hc]' | grep -v 
'/tmp_check/' | grep -v '/Debug/' | xargs egrep -i -B3 -A3 
'\b(him|her|his|hers|he|she)\b'
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * isNatural, usingClause, and quals are 
interdependent.  The user can write
./src/include/nodes/primnodes.h- * only one of NATURAL, USING(), or ON() (this 
is enforced by the grammar).
./src/include/nodes/primnodes.h: * If he writes NATURAL then parse analysis 
generates the equivalent USING()
./src/include/nodes/primnodes.h- * list, and from that fills in "quals" with 
the right equality comparisons.
./src/include/nodes/primnodes.h: * If he writes USING() then "quals" is filled 
with equality comparisons.
./src/include/nodes/primnodes.h: * If he writes ON() then only "quals" is set.  
Note that NATURAL/USING
./src/include/nodes/primnodes.h- * are not equivalent to ON() since they also 
affect the output column list.
./src/include/nodes/primnodes.h- *
./src/include/nodes/primnodes.h- * alias is an Alias node representing the AS 
alias-clause attached to the
--
./src/include/c.h-/*
./src/include/c.h- * MemSetAligned is the same as MemSet except it omits the 
test to see if
./src/include/c.h- * "start" is word-aligned.  This is okay to use if the 
caller knows a-priori
./src/include/c.h: * that the pointer is suitably aligned (typically, because 
he just got it
./src/include/c.h- * from palloc(), which always delivers a max-aligned 
pointer).
./src/include/c.h- */
./src/include/c.h-#define MemSetAligned(start, val, len) \
--
./src/bin/pg_dump/pg_backup_directory.c-typedef struct
./src/bin/pg_dump/pg_backup_directory.c-{
./src/bin/pg_dump/pg_backup_directory.c-/*
./src/bin/pg_dump/pg_backup_directory.c: * Our archive location. This 
is basically what the user specified as his
./src/bin/pg_dump/pg_backup_directory.c- * backup file but of course 
here it is a directory.
./src/bin/pg_dump/pg_backup_directory.c- */
./src/bin/pg_dump/pg_backup_directory.c-char   *directory;
--
./src/backend/nodes/makefuncs.c-tle->resname = resname;
./src/backend/nodes/makefuncs.c-
./src/backend/nodes/makefuncs.c-/*
./src/backend/nodes/makefuncs.c: * We always set these fields to 0. If 
the caller wants to change them he
./src/backend/nodes/makefuncs.c- * must do so explicitly.  Few callers 
do that, so omitting these
./src/backend/nodes/makefuncs.c- * arguments reduces the chance of 
error.
./src/backend/nodes/makefuncs.c- */
--
./src/backend/parser/parse_clause.c- *we may as well accept this 
common extension.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * Note that pre-existing resjunk 
targets must not be used in either case,
./src/backend/parser/parse_clause.c: * since the user didn't write them in 
his SELECT list.
./src/backend/parser/parse_clause.c- *
./src/backend/parser/parse_clause.c- * If neither special

Re: [HACKERS] Make primnodes.h gender neutral

2016-03-18 Thread Tom Lane 
Peter Geoghegan  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