Re: [GENERAL] CoC [Final v2]

[David E. Wheeler]

On Jan 24, 2016, at 5:25 PM, Joshua D. Drake  wrote:

> In retrospect I revoke my support of this idea entirely. It just isn't our 
> jurisdiction. If doesn't happen in our yard then it isn't our business.

Then know that the current draft of the CoC is easily interpreted as giving 
shelter to abusers.

> I would also note that this document isn't going to be the end all of 
> enforcement. Ultimately -core has the final say. -Core can determine on its 
> own if it wants to enforce against a particular community member (with or 
> without the CoC).

Yep. And as Chrisophe pointed out, none of it will mean anything without an 
explicit and enforced policy for dealing with violations.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] CoC [Final v2]

[David E. Wheeler]

On Jan 24, 2016, at 11:28 AM, Chris Travers  wrote:

>> * PostgreSQL is a community project and takes no position on any
>> political question aside from its usage in the public sector (which we
>> support).  We expect communication in community fora to respect this
>> need.  The community is neither competent nor interested in resolving
>> more general social or political questions.  Nonetheless the core team  does 
>> make an effort at ensuring an atmosphere where all people, regardless of 
>> background feel generally welcome.
> 
> I think that would address David Wheeler's concern too.

Alas, no, as it does not address abuse.

> Suppose someone from a divisive organization using PostgreSQL were to make a 
> speech at a PostgreSQL conference about a technical topic.  Would that be 
> off-limits just because they are politically divisive as an organization?

If they make hateful statements about members of the community, or to 
interested parties who then report them to the community, then yes. Otherwise, 
we’re saying we’re okay with abuse of any kind as long as it’s not on our turf. 
It’s not politics, it’s hate.

Best,

David

smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] CoC [Final v2]

[David E. Wheeler]

On Jan 24, 2016, at 2:34 PM, Joshua D. Drake  wrote:

> O.k. now I am starting to see your point. For example:

o_O

> Pg person A is harassing person B in the Rails community.
> 
> How do we deal with that?
> 
> 1. If person B is not in the Pg community then it is up to the Rails 
> community to deal with it.
> 
> 2. If person B is in the Pg community they can request help.
> 
> I am open to wording on #2. I tried a couple of times but had trouble not 
> making it a larger declaration that I think it needs to be.

How do you define “in the Pg community”? Is it someone who has posted to a 
known forum at least once? Someone who has been to a conference? What if they 
have never participated in a community forum, but use PostgreSQL at work? Maybe 
they would eventually submit a bug report or ask a question. How do you gauge 
that?

Me, I don’t think you can. If someone reports abusive behavior by a member of 
the Pg community, it should not matter whether or not the person doing the 
reporting is a member of the community, only that the reported abuser is.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] CoC [Final v2]

[David E. Wheeler]

On Jan 24, 2016, at 2:41 PM, Christophe Pettus  wrote:

> What is missing from this, first and foremost, is a reporting and resolution 
> mechanism.  If someone feels the CoC has been violated, who do they talk to?  
> How does that person or entity resolve things?  What confidentiality promises 
> are made?

I think that’s planned for a separate document, to be linked. But it need to be 
put in place at the same time, IME. Otherwise the CoC on its own has no teeth.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 6:14 PM, Joshua D. Drake  wrote:

> You can not violate one part of the CoC and use the other part as the reason.

You say, that, and yet someone will. Think about law: if laws contradict each 
other, a person accused of violating one law will use the other in their 
defense.

> A Code of Conduct should protect all, equally and without bias.

Says someone who requires no protection at all.

Best,

David




smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 23, 2016, at 1:59 PM, Steve Litt  wrote:

> We all need the necessary protection, which is not necessarily equal
> protection, because some of us are subjected to much more harassment.
> And I think we all need to walk a mile in other peoples shoes before
> assuming others need only the meager amount of protection we need.

Thank you, Steve, well said.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 23, 2016, at 3:43 PM, Joshua D. Drake  wrote:

> I have been accused of being a fat hater. My crime? I suggested that 
> generally speaking, obesity is a matter of diet and exercise. Worse? The 
> individual started the conversation and I am also classified as obese 
> (barely, I won't be in a month).
> 
> I have been accused of being sexist because I asked if there was chalk (for 
> bouldering) that was better for women because their skin is generally softer 
> and the chalk wasn't staying on the respective persons hand. A scientific 
> sexist fact.
> 
> I have been accused of being sexist because I said it wasn't sexist that 
> Samsung doesn't make full feature/performance phones that are smaller for a 
> woman's hands.

So are you able to recognize the ways in which those statements can come across 
as prejudiced? We *all* make mistakes. Ideally what one does is to try to 
recognize them and take responsibility for them. An *abuser* will do neither.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] CoC [Final v2]

[David E. Wheeler]

On Jan 22, 2016, at 6:47 PM, Joshua D. Drake  wrote:

> This document provides community guidelines for a safe, respectful, 
> productive, and collaborative place for any person who is willing to 
> contribute to the PostgreSQL community. It applies to all "collaborative 
> space", which is defined as community communications channels (such as 
> mailing lists, IRC, submitted patches, commit comments, etc.).

We need to also cover abuse by members of the community made outside the 
community. Otherwise we’ll appear to give safe harbor to abusers.

> * Participants will be tolerant of opposing views.

This statement can be used in defense of abusive behavior (“I was just 
expressing an opposing view!”).

> * Participants must ensure that their language and actions are free
> of personal attacks and disparaging personal remarks.
> 
> * When interpreting the words and actions of others, participants
> should always assume good intentions.

This statement can be used in defense of abusive behavior (“You should 
recognize the intention behind what I said was benign!”).

> * Behaviour which can be reasonably considered harassment will not be 
> tolerated.

Link to enforcement policy will of course be required.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

Hi PostgreSQL General.

I get that my short, snarky posts don’t help my argument, but I admit to being 
a bit frustrated that the posts wherein I have tried to lay out a position get 
little or no response. So let me try again.

1. Items in the current draft of the CoC can be manipulated by abusers to claim 
that they were just expressing an opinion or were ignorant of their tone. The 
ability to say that, and reference a specific item in the CoC when doing so, 
introduces an element of inconsistency that can lead people to doubt that 
statements are in violation of the CoC. One might think that “You can not 
violate one part of the CoC and use the other part as the reason”, and yet that 
is exactly what is likely to happen. One can, and one will, and then how will 
those evaluating a case of reported abuse handle it? If someone says, “I was 
abused as defined in Bullet 2,” but the abuser says, “I am protected in my 
speech by Bullets 1 and 3,” what’s going to happen?

Related: http://paddy.io/posts/professional-concerns/

2. This document has been written and edited, in the main, by people who have 
not, to my knowledge, experienced the kind of abuse we want to prevent. Nor do 
they have experience in writing a document like this in such a way to make it 
consistent and effective, and to make targets of abuse feel safe here. We 
really should be taking advantage of the expertise of those who have 
experienced these issues, who have seen what has worked and what hasn’t, and 
can advise us on the most likely approach for success. The Contributor Covenant 
tries to encapsulate such expertise in a way that’s easy for communities to 
develop. But if our community doesn’t like the Covenant, I think we should 
bring in the expertise to help us craft a document that’s likely to be the most 
effective. There are a number of consultants in this space who have 
tremendously helped other communities I’ve participated in, such as the XOXO 
Festival.

3. If I understand correctly, the impetus for adopting a CoC (which, believe 
me, I laud in no uncertain terms) was this post by Randi Harper about her 
experience reporting abuse to the FreeBSD community:

  http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/

Ideally, by adopting a CoC and an enforcement policy, we can try to prevent bad 
experiences for people reporting abuse. However, in this example, the abuse, 
which came from a FreeBSD committer and was aimed at another, took place on 
Twitter, not in a FreeBSD forum. However, the rules of the FreeBSD community at 
that time did not cover abuse outside sanctioned community forums. As a result, 
the FreeBSd core:

> weren’t willing to take action on threats because they didn’t happen on the 
> mailing list — despite them happening in a venue where the committer publicly 
> identified himself as a member of the project. 

The proposed CoC does not cover this situation, either, at least not as 
directly as it should. So if someone who identified as a PostgreSQL community 
member abused someone else on Twitter or Facebook, and that abuse was reported 
to the PostgreSQL community (by whatever policy the community will need to 
spell out), will the abuse enforcement team be able to do anything about it, by 
the proposed CoC? I suspect not. The third bullet item refers only to the 
community “collaborative space”. It should also cover forums outside the 
community’s own collaborative spaces. Otherwise, if someone in our community 
abuses someone in an outside forum, but is allowed to continue to participate 
in the community, then the target of that abuse will not feel safe here. The 
abuser, however, will. Is that an outcome we really want? If not, how do we 
make explicit that it won’t happen?

Look, I’m not an authority on this stuff, either. But I understand that rules, 
such as those in a Code of Conduct, must be explicit and as unambiguous as 
language will allow. And it’s pretty easy for me, a non-expert in the fields of 
law or abuse mitigation, to see oversights and contradictions that can and will 
be exploited by abusers. We should close them. Ideally the core organization 
would hire one or more experts to help us out, or else would take advantage of 
the fruits of their past labors and adopt something that has already been 
thought-through by experts and adopted by a wide range of communities. Will it 
be perfect? No. Can we make it good enough to make people feel safe? Absolutely.

This isn’t about compromise, mind. If what we want to do is to let people know 
that they are safe from abuse in this community and from members of this 
community, that we take abuse seriously and will act on reports expeditiously, 
then I don’t see how the proposed CoC get us there.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 10:35 AM, Rajeev Bhatta  wrote:

> Any process or change is perfected over course of time.. The current CoC may 
> not be perfect but time will make it. 

It is better than none, I’ll grant you, but it could be SOOO much better right 
now.

> Ideas can be solicited from other groups but CoC should be created and 
> enforced by our community alone… 

It’s fair to draw on the experience and expertise of others who have gone 
before us, yes.

>> BTW, I am one of those “through someone else” people of which you speak. 
> 
> I am sorry to hear that... The fact that you are raising your opinion shows 
> your passion for postgres project which is very appreciated and I hope if 
> there are others they should be back and see that there is an effort to 
> minimize the ill treatment they had to suffer. 

Oh, no doubt, but the fact that they’re not participating (or barely) shows 
that the current proposal is insufficient.

Best,

David

smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 9:44 AM, Geoff Winkless  wrote:

>> BTW, I am one of those “through someone else” people of which you speak.
> 
> Excellent! Then can you ask the person for whom you are "someone else"
> to explain exactly which parts of the projected CoC are unacceptable?
> Because the only way in which I can see it doesn't align with the
> Contributor Covenant is that the CoC doesn't consider someone's
> personal opinions, either private or expressed outside the Postgresql
> arena, to be the responsibility of the Postgres team.

If this is the latest:

  http://postgresql.nabble.com/CoC-Final-td5882762.html

Then:

> * We are tolerant of people’s right to have opposing views. 

This point allows anyone who has been reported for a violation to say that they 
simply have an opposing point of view, and why can’t you respect that? It’s an 
out for anyone in violation.

> * Participants must ensure that their language and actions are free 
> of personal attacks and disparaging personal remarks. 

This allows a violator to claim ignorance. The “I didn’t know I was being 
harassing!” ‘defense’ works.  It plays into the “geeks are  bad at social” 
fallacy, and completely ignores that a lot of abusers intentionally craft “oh I 
didn’t know” stories/personas to get away with their abuse.

> * When interpreting the words and actions of others, participants 
> should always assume good intentions. 

This allows the “I didn’t realize my tone was off, can’t you assume I have good 
intentions?” defense.

> * Participants who disrupt the collaborative space, or participate in a 
> pattern of behaviour which could be considered harassment will not be 
> tolerated. 

This should point to a policy for handling violations. What does “will not be 
tolerated” mean? It needn’t be spelled out in the CoC, but it must be spelled 
out and pointed at from the CoC.

This document sounds like something written by well-meaning folks who don’t 
want to be misunderstood. There is a lot here to let violators protect 
themselves in the event of a reported violation, but little to make vulnerable 
people feel safe. It is the latter that needs to be the message of the CoC, not 
the former.

Those of us who fear offending without meaning to, or being misunderstood, can 
best serve the aims of a CoC -- openness and safety -- by being open to 
learning from our mistakes rather than trying to defend them on the basis of 
intent.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 9:43 AM, Regina Obe  wrote:

> Again sorry for cutting thread.  I just get the digest.

No worries. :-)

> Ruby is under heavy threat to adopt this, but they have not yet to my 
> knowledge.  Here is the thread:

Threat?

> https://bugs.ruby-lang.org/issues/12004
> 
> Reading the thread requires a lot of attention and also face recognition.  So 
> I shall point out the actors and actresses in this conversation you should 
> pay close attention to:
> 
> Coraline Ada -  https://www.patreon.com/coraline?ty=h - Please give money to 
> her cause, as it's way more important than the poor folk who work to make 
> PostgreSQL better for free and never ask you for a dime

$300 a month to work on promoting diversity in open-source projects? It’s worth 
*so* much more than that.

> Kurtis Rainbolt-Greene -  
> https://twitter.com/krainboltgreene/status/611569515315507200  
> https://github.com/opal/opal/issues/941 
> Yes indeed he was very angered at Elia's (key Opal developer) saying gender 
> reassignment is wrong for young children, and spending like $50,000 on gender 
> reassignment is being out of touch with reality.  Like me saying smokers are 
> killing themselves and spending money on 3 packs of cigrarettes a day could 
> be better used.

I don’t follow.

> Strand McCutchen - https://github.com/opal/opal/issues/942  (wow what a 
> trooper, he's going to help Opal polish off the Contributor Convenant so it's 
> in a shape they can accept)

Looks like it went in.

  https://github.com/opal/opal/blob/master/CODE_OF_CONDUCT.md

> Ruby Creator - Yukihiro Matsumoto
> And you must agree after seeing all the evidence that Yukihiro Matsumoto (who 
> is not even a white guy) inventor of ruby must be a jerk for not adopting 
> this wonderful thing to make people feel welcome and respected.  What awful 
> person would not.  How about me?

It depends on his reasons, I suppose. 

> Let's not forget about Meredith Patterson -  
> https://www.youtube.com/watch?v=AI53yys3dbA=youtu.be=538  What has 
> she done for open source?
> Please ignore the two white guys in the talk, they are just white guys with 
> white guy opinions.

They are in fact both unreconstructed bigots.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 11:28 AM, Magnus Hagander  wrote:

> Regardless whether it's true or not (to which I cannot speak), surely 
> statements like that would violate *both* the contributor covenant *and* the 
> CoC suggested by others.

It may well violate the Contributor Covenant (my apologies, I was out of line), 
but not the current draft of the CoC, IME. Why? Because that’s just my opinion, 
and the CoC draft formally recognizes my right to have an “opposing view”.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 11:47 AM, Luz Violeta  wrote:

> P.S → even now, I'm kinda terrified of a shitstorm in my first mail to the 
> mailing list ... but definitely this spark of hope made me come forward and 
> say something, dunno.

Thank you so much for doing so. Up to now it’s just been one more white guy 
(me) saying something. The more folks who can constructively contribute -- and 
especially to shine a light on the contexts of which many of us are unaware -- 
the better the likelihood of getting something that creates the safe 
environment I firmly believe we all want.

Best,

David

smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 11:47 AM, Steve Litt  wrote:

> Speaking up is a privilege often reserved for the in crowd and the
> revolutionary.

+1000

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 3:15 PM, Kevin Grittner  wrote:

> I do wonder what it is that made you terrified of a shitstorm, and
> what it is that you're hoping for that you don't feel is already
> present.

Regina linked to some shitstorms in the Opal and Ruby communities. Shitstorms 
are not unusual when people ask for a CoC.

> Not only do I want that, but I thought we had it.  I have still not
> seen anything to show me otherwise; the hypothetical examples I can
> remember seeing on these recent threads bear no resemblance to
> anything I can remember ever seeing on the PostgreSQL lists.  Can
> you point to something as an example of the kind of behavior that
> you think a Code of Conduct would have prevented?

My own behavior earlier is not a terrible example. By one point on the CoC (“ 
language and actions are free 
of personal attacks and disparaging personal remarks”), it seems problematic if 
not an outright violation. But one can argue by another point (“tolerant of 
people’s right to have opposing views”) that it’s totally within bounds. So the 
demarcations of right and wrong are too easily subject to debate and further 
disagreement. Less ambiguity and contradiction is required.

> Regarding the question of the Code of Conduct having short, general
> statements versus listing "protected groups", etc. -- I would like
> to see everyone protected.  Any list, by its nature, is going to
> make someone feel excluded and unprotected.  In my view, the closer
> it is to a statement of "The Golden Rule"[1], the better.

Some of us do not need protection; we are already privileged members of the 
community. Therefor it’s important to spell out whom we aim to protect.

> In particular, I think that if (hypothetically) someone who is part
> of the community makes some idiotic, offensive, insensitive
> statement of blathering idiocy *outside PostgreSQL forums*, they
> should enjoy the same right to respect and prevention of attack *on
> the PostgreSQL forums* as everyone else.

What if they psychologically abused someone in person, perhaps another member 
of the community, but in a non-community context? Should there be no 
repercussions?

> They just better not
> repeat the idiocy here.  I would hope that major contributors would
> keep in mind the impact that such statements in other venues might
> have on the public perception of the community.  I've come around
> to the point of view that encouraging such consideration is outside
> the scope of what a Code of Conduct should formally address.

In my above example, the victim of the abuse would not feel safe in our 
community, because their abuser would still be a member in good standing. Even 
if they reported that behavior, the would have no expectation of anything being 
done to address it. In this example, the abuser ends up protected by the CoC 
while the victim is not.

This is a very real thing that happens to real people in communities every day. 
IME, we want people to feel safe reporting incidents even if they occur outside 
the community, and that such reports will be taken seriously, with an explicit 
policy for doing so.

> The PostgreSQL forums should be a safe place, and rancor engendered
> elsewhere should not be brought in.  Problems should be resolved in
> a way that minimizes the chance of escalation, recognizing that
> there could be miscommunication.[2]

Rancor isn’t the problem as much as abuse. And most abuse you can’t see unless 
the targets of such abuse feel safe reporting them.

Limiting the policy to community forums is insufficient for making people feel 
safe. This is the whole reason for v1.3.0 of the Contributor Covenant:

  https://github.com/CoralineAda/contributor_covenant/blob/master/changelog#L7

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 12:49 AM, Joshua D. Drake  wrote:

>> Additionally the CoC emails were sent to the entire group so it was open
>> for all. I did not read the remainder of the email as classifying
>> someone by anything is inappropriate.
> 
> +1

The fact that it was “open for all” does not mean that it was an inclusive 
discussion.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 12:39 AM, Regina Obe  wrote:

> I am especially disgusted by the people behind 
> http://contributor-covenant.org.  They have done nothing but to silence the 
> voices of minorities. That's being kind to them.

Interesting. Got a link for context? I Googled, but saw nothing about 
controversy or other issues in the first few pages. Maybe I need to dig a 
little deeper?

Honestly, I like that other folks have really thought this stuff through, and 
it’s so widely adopted as to be approaching a standard for OSS.

> Which essentially says - "we are individuals with a common love for this 
> thing, get to know who we are, jump in to help us and your voice will be 
> heard."
> That's pretty much all I care about when getting involved in any  community.

Right, but it’s not enough for other people, so insufficiently inclusive.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 9:18 AM, Adrian Klaver  wrote:

>> The fact that it was “open for all” does not mean that it was an inclusive 
>> discussion.
> 
> To the extent that everybody that participates in the list and would be 
> subject to it had an opportunity to comment, yes it was inclusive.

It excludes people who don’t participate in the list because of issues they’ve 
had there in the past. Best way for it to be inclusive is to either bring those 
people back in, or to adopt some sort of standard CoC that people in similar 
positions have developed through hard thinking and hard experience over time.

Best,

David




smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] Let's Do the CoC Right

[David E. Wheeler]

On Jan 22, 2016, at 9:25 AM, Adrian Klaver  wrote:

>> It excludes people who don’t participate in the list because of issues 
>> they’ve had there in the past.
> 
> When and whom? This is the time for those that had issues to speak up either 
> directly or through someone else. In doing so though I would expect 
> verifiable information.

So here we have a chicken-and-egg issue. If there is no CoC (or an insufficient 
one), then people who have been hurt in the past don’t want to participate. You 
need the security of a CoC before it’s safe to come back. It is not up to them 
to prove themselves to you, to verify that they have suffered just for some 
sort of confirmation for you.

The way to involve a broader audience is to solicit feedback from outside the 
immediate confines of a single mail list. Or even the community itself. People 
have left the community because of issues; how do you get their help fixing the 
things over which they left?

BTW, I am one of those “through someone else” people of which you speak.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

[GENERAL] Let's Do the CoC Right

[David E. Wheeler]

Fellow PostgreSQLers,

I can’t help that there are a whole lot of white guys working on this document, 
with very little feedback from the people who it’s likely to benefit (only 
exception I spotted in a quick scan was Regina; sorry if I missed you). I 
suspect that most of you, like me, have never been the target of the kinds os 
behaviors we want to forbid. Certainly not to the level of many women, 
transgendered, and people of color I know of personally, in this community and 
others, who have. If those people are not speaking up here, I suspect it’s 
because they don’t expect to be heard. A bunch of white guys who run the 
project have decided what it’s gonna be, and mostly cut things out since these 
threads started.

But a *whole* lot of thought has gone into the creation of CoCs by the people 
who need them, and those who care about them. They have considered what sorts 
of things should be covered, what topics specifically addressed, and how to 
word them so as to enable the most people possible to feel safe, and to 
appropriately address issues when they inevitably arise, so that people 
continue to feel safe.

So I’d like to propose that we not try to do this ourselves. Instead, I propose 
that we take advantage of the ton of thought others have already put into this, 
and simply:

* Follow the example of many other successful communities (Swift, Mono, Rails, 
and 10,000 others) and adopt the open-source Contributor Covenant, unmodified.

  http://contributor-covenant.org

* Put this document in the root directory of the project as CODE_OF_CONDUCT.md, 
so that anyone who wants to contribute can. It should also be listed on the 
main web site and referenced from appropriate places (such as the mail lists 
pages).

* Spell out a policy and procedure for enforcement and include it as a separate 
document, again in the Git rep and on the site. The reporting address should be 
included in the Covenant. The Covenant web site has links to a number of 
existing guides we ought to crib from.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

[GENERAL] Let's Do the CoC Right

[David E . Wheeler]

Fellow PostgreSQLers,

I can’t help that there are a whole lot of white guys working on this document, 
with very little feedback from the people who it’s likely to benefit (only 
exception I spotted in a quick scan was Regina; sorry if I missed you). I 
suspect that most of you, like me, have never been the target of the kinds os 
behaviors we want to forbid. Certainly not to the level of many women, 
transgendered, and people of color I know of personally, in this community and 
others, who have. If those people are not speaking up here, I suspect it’s 
because they don’t expect to be heard. A bunch of white guys who run the 
project have decided what it’s gonna be, and mostly cut things out since these 
threads started.

But a *whole* lot of thought has gone into the creation of CoCs by the people 
who need them, and those who care about them. They have considered what sorts 
of things should be covered, what topics specifically addressed, and how to 
word them so as to enable the most people possible to feel safe, and to 
appropriately address issues when they inevitably arise, so that people 
continue to feel safe.

So I’d like to propose that we not try to do this ourselves. Instead, I propose 
that we take advantage of the ton of thought others have already put into this, 
and simply:

* Follow the example of many other successful communities (Swift, Mono, Rails, 
and 10,000 others) and adopt the open-source Contributor Covenant, unmodified.

 http://contributor-covenant.org

* Put this document in the root directory of the project as CODE_OF_CONDUCT.md, 
so that anyone who wants to contribute can. It should also be listed on the 
main web site and referenced from appropriate places (such as the mail lists 
pages).

* Spell out a policy and procedure for enforcement and include it as a separate 
document, again in the Git rep and on the site. The reporting address should be 
included in the Covenant. The Covenant web site has links to a number of 
existing guides we ought to crib from.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] pgxs/config/missing is... missing

[David E. Wheeler]

On Oct 29, 2015, at 7:22 PM, Jim Nasby  wrote:

> I'm not sure if this is the right way to go about it, but this patch at least 
> installs the file.

Which seems like a decent idea. I’d like a way to know when Perl is missing, 
though. What does `missing` do?

D

smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] pgxs/config/missing is... missing

[David E. Wheeler]

On Oct 30, 2015, at 11:38 AM, Jim Nasby  wrote:

> Given what pgTap's Makefile is using perl for, perhaps the best bet is to 
> just ignore whatever PGXS has to say about it.

So add a check to see if it ends in “missing perl”? Suggested Makefile-foo for 
that?

D



smime.p7s
Description: S/MIME cryptographic signature

Re: [GENERAL] pgxs/config/missing is... missing

[David E. Wheeler]

On Oct 28, 2015, at 10:54 AM, Jim Nasby  wrote:

> I indeed get
> 
> PERL = /bin/sh 
> /usr/local/lib/postgresql/pgxs/src/makefiles/../../config/missing perl

Ew.

> even after explicitly exporting PERL=/usr/local/bin/perl

Hrm. I have this code in the pgTAP Makefile:

ifndef PERL
PERL := $(shell which perl)
endif

Could that be causing the problem?

> I see that there is a config/missing script in source, and that 
> Makefile.global.in references it:
> 
>> src/Makefile.global.in:missing= $(SHELL) 
>> $(top_srcdir)/config/missing
> 
> Any ideas why it's not being installed, or why the PGXS Makefile is 
> ignoring/over-riding $PERL?

That I surely don’t know. :-(

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

[GENERAL] Functions To Let Users Cancel/Terminate own Back Ends

[David E. Wheeler]

PostgreSQLers,

I have a need at my $dayjob to let users cancel their own back ends. See any 
issues with this function to allow them to do that? Any security gotchas or 
anything?

CREATE OR REPLACE FUNCTION iov_cancel_user_backend(
pid INTEGER
) RETURNS BOOLEAN LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
   username NAME;
BEGIN
SELECT usename INTO username FROM iov_catalog.iov_stat_activity WHERE 
procpid = pid;
IF username IS NULL THEN RETURN FALSE; END IF;

IF username  session_user THEN
RAISE EXCEPTION 'You do not own back end %', pid;
END IF;

RETURN iov_catalog.pg_cancel_backend(pid);
END;
$$;

I plan to have one that calls pg_terminate_backend(), as well.

Thanks,

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

Re: [GENERAL] Functions To Let Users Cancel/Terminate own Back Ends

[David E. Wheeler]

On Feb 2, 2012, at 2:51 PM, Magnus Hagander wrote:

 I have a need at my $dayjob to let users cancel their own back ends. See any 
 issues with this function to allow them to do that? Any security gotchas or 
 anything?
 
 You mean something like this?
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0495aaad8b337642830a4d4e82f8b8c02b27b1be
 
 (So yes, the principle was agreed to be safe)

Oh, it *was* committed? Excellent. Yeah, looks pretty similar in principal. 
Thanks!

David


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

Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme

[David E. Wheeler]

On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:

 I prefer to dump all my data in a big text file and grep it for the 
 information I need.
 
 As long as you implement your own grep, that sounds about on par with
 the current trends! Go for it!

Well, first you have to implement your own compiler. Also a lexer and a parser.

David


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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote:


In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.

My impression was that among the change options, 2b had the most  
support (it is the most useful for the use-cases I've encountered so  
it gets my vote). If the consensus is to change the function, it may  
be too late for 8.4. But the documentation could be updated to  
reflect current and planned behavior.


+1

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:


my @ints = map { $_ || 0 } split ',', $string;

This ensures that I get the proper number of records in the example  
of something like '1,2,,4'.


I can't see that there's any way to do this in SQL regardless of how
we define this operation.


It's easy enough to write a function to do it:

CREATE OR REPLACE FUNCTION trim_blanks (anyarray) RETURNS anyarray AS $$
SELECT ARRAY(
SELECT CASE WHEN $1[i] IS NULL OR $1[i] = '' THEN '0' ELSE  
$1[i] END

  FROM generate_series(1, array_upper($1, 1)) s(i)
 ORDER BY i
);
$$ LANGUAGE SQL IMMUTABLE;

Best,

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:


Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does).  The former is sounding less likely to bite people
unexpectedly.


Right, very well put.


Or we could stick to the current behavior and say use COALESCE() to
resolve the ambiguity, if you need to.


Steve has a point that leaving it as-is leaves it as impossible to  
tell the difference between string_to_array(NULL, ',') and  
string_to_array('', ','). The former properly handles an unknown  
value, while the latter, where '' is a known value, seems weird to be  
returning NULL.


Best,

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:

Yes, I'd be tempted to pick one and go with it.  It's seems a  
completely

arbitrary choice one way or the other but the current behaviour is
certainly wrong.

I'd go with returning a zero element array because it would do
the right thing more often when paired with array_to_string.
I've also been through the first few pages of a Google search for
array_to_string and it seems to do the right thing for the  
majority

of the cases.


Forgive me if I'm missing something, but it seems to me that  
array_to_string() works either way, no?


try=# select '' || array_to_string('{}'::text[], ',') || ''; ?column?
--
 
(1 row)

Time: 72.129 ms
try=# select '' || array_to_string('{}'::text[], ',') || '';
 ?column?
--
 
(1 row)

Best,

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:


+1.  I find this argument much more compelling than anything else
that's been offered up so far.


Yeah.  It seems to me that if you consider only the case where the  
array
elements are text, there's a weak preference for considering '' to  
be a
single empty string; but as soon as you think about any other  
datatype,

there's a strong preference to consider it a zero-element list.  So I
too have come around to favor the latter interpretation.  Do we have
any remaining holdouts?


Well, I'd just point out that the return value of string_to_array() is  
text[]. Thus, this is not a problem with string_to_array(), but a  
casting problem from text[] to int[]. Making string_to_array() return  
a NULL for this case to make casting simpler is addressing the problem  
in the wrong place, IMHO. If I want to do this in Perl, for example,  
I'd do something like this:


my @ints = grep { defined $_  $_ ne '' } split ',', $string;

So I split the string into an array, and then remove unreasonable  
values. This also allows me to set defaults:


my @ints = map { $_ || 0 } split ',', $string;

This ensures that I get the proper number of records in the example of  
something like '1,2,,4'.


So I still think that string_to_array('', ',') should return '{}',  
and how casting is handled should be left to the user to flexibly  
handle.


That said, I'm not seeing a simple function for modifying an array.  
I'd have to write one for each specific case. :-(


Best,

David




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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 1, 2009, at 10:09 AM, Tom Lane wrote:


Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].


Nonsense.  The question is whether string_to_array is meant to be  
useful

for lists of anything except text.  I agree you could argue that it
isn't.  But even in the domain of text it's not all that cut-and-dried
whether string_to_array should return array[] or array[''] for empty
input.  So ISTM we're giving up less than we gain by choosing the  
former.


Yeah. I'm okay with either, as long as it's consistent. I have a mild  
preference for '{}', but I can live with ARRAY[] instead. As long as  
it's not NULL that gets returned.


Best,

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Apr 1, 2009, at 10:05 AM, justin wrote:


string_to_array('',',')::INT[]  works as proposed

But
string_to_array(',,,', ',' )::INT[]   Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .


I'm trying to understand the difference between a empty string to a  
string with  many blank entries between  the delimiter.
Consider   ',,'  = ''  once the delimiter is removed .  Yet  
Seven zero length entries were passed.  How is that going to be  
handled


Right, it's making a special case of '', which does seem rather  
inconsistent to me.


Best,

David

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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Mar 31, 2009, at 8:34 AM, Sam Mason wrote:


What do you really expect to be returned for things like

select count_elements(string_to_array('butter,tea,milk',','))


3 = {butter,tea,milk}


select count_elements(string_to_array('butter,tea',','))


2 = {butter,tea}


select count_elements(string_to_array('butter',','))


1 = {butter}


select count_elements(string_to_array('',','))


1 = ARRAY['']


I'd expect 3,2,1 and 1.

That's also a disingenuous example; what would you expect back from:

 select count_elements(string_to_array('butter,,milk',','))


3 = ARRAY['butter', '', 'milk']


I think the semantics you want is what you'd get from:

 array_filter_blanks(string_to_array($1,$2))

where I defined array_filter_blanks in my previous post.


Yeah, if I wanted something like that in Perl, I'd do:

  my @stuff = grep { $_ } split /,/, $string;

In no case would I ever expect a NULL, however, unless I was trying to  
split on NULL.


NULL = string_to_array(NULL, ',');

Best,

David


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

Re: [HACKERS] [GENERAL] string_to_array with empty input

[David E. Wheeler]

On Mar 30, 2009, at 8:26 PM, Tom Lane wrote:


Does anyone want to argue for keeping it the same?  Or perhaps
argue that a zero-element array is a more sensible result than
a one-element array with one empty string?  (It doesn't seem
like it to me, but maybe somebody thinks so.)


Hrm. There seems to be some disagreement about this among some  
languages:


% perl -le '@r = split /-/, ; print length @r; print qq{$r[0]}'
1


% irb
 puts ''.split('-')
= nil

So Perl returns a single element as Steve had been expecting, while  
Ruby returns nil. I'm used to the Perl way, but I guess there's room  
for various interpretations, including the current implementation,  
with which Ruby would seem to agree.


Best,

David

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