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 abus
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
>
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 d
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 neith
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
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 meag
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
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
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.
>
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 whe
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
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
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 w
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 gr
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 th
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
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
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 ex
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 abou
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
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 neve
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 neve
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 c
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 cryp
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 := $
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=
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 DEFIN
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
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 e
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 ofte
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 le
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'
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
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. B
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
sing
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(stri
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
37 matches
Mail list logo
