Re: Code of Conduct plan

[Mark Kirkwood]

On 15/09/18 08:17, Tom Lane wrote:

Yeah, this.  The PG community is mostly nice people, AFAICT.  I'll be
astonished (and worried) if the CoC committee finds much to do.  We're
implementing this mostly to make newcomers to the project feel that
it's a safe space.


Agreed. However I think the all-of-life clause gives an open door to 
potential less than well intentioned new members joining up to extend a 
SJW agenda. So in fact the unintended consequence of this may be a 
*less* safe place for some existing members - unless all of their social 
media utterances are agreeable to the angry militant left.



It's also worth reminding people that this is v1.0 of the CoC document.
We plan to revisit it in a year or so, and thereafter as needed, to
improve anything that's causing problems or not working well.


+1, At least this means we can address the above if it emerges as a problem

regards
Mark


regards, tom lane

Re: Code of Conduct plan

[Adrian Klaver]

On 9/14/18 11:13 AM, Robert Haas wrote:

On Fri, Sep 14, 2018 at 11:10 AM, Dave Page  wrote:

That wording has been in the published draft for 18 months, and noone
objected to it that I'm aware of. There will always be people who don't like
some of the wording, much as there are often people who disagree with the
way a patch to the code is written. Sooner or later though, the general
consensus prevails and we have to move on, otherwise nothing will ever get
completed.


It's not clear to me that there IS a general consensus here.  It looks
to me like the unelected core team got together and decided to impose
a vaguely-worded code of conduct on a vaguely-defined group of people
covering not only their work on PostgreSQL but also their entire life.
It is not difficult to imagine that someone's private life might
include "behavior that may bring the PostgreSQL project into
disrepute."

However, I also don't think it matters very much.  The Code of Conduct
Committee is going to consist of small number of people -- at least
four, perhaps a few more.  But there are hundreds of people involved
on the PostgreSQL mailing lists, maybe thousands.  If the Code of
Conduct Committee, or the core team, believes that it can impose on a
very large group of people, all of whom are volunteers, some set of
rules with which they don't agree, it's probably going to find out
pretty quickly that it is mistaken.  If people from that large group
get banned for behavior which is perceived by other members of that
large group to be legitimate, then there will be a ferocious backlash.
Nobody wants to see people who are willing to contribute driven away
from the project, and anyone we drive away without a really good
reason will find some other project that welcomes their participation.
So the only thing that the Code of Conduct Committee is likely to be
able to do in practice is admonish people to be nicer (which is
probably a good thing) and punish really egregious conduct, especially
when committed by people who aren't involved enough that their absence
will be keenly felt.

In practice, therefore, democracy is going to win out.  That's both
good and bad.  It's good because nobody wants a CoC witch-hunt, and
it's bad because there's probably some behavior which legitimately
deserves censure and will escape it.



+1

--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Code of Conduct plan

[Adrian Klaver]

On 9/14/18 11:21 AM, Peter Geoghegan wrote:

On Fri, Sep 14, 2018 at 11:06 AM, Dimitri Maziuk  wrote:

Personally I would like that. Others might prefer an invitation to
unsubscribe or forever hold their peace, I could live with that too, but
I believe explicit opt-ins are preferable to opt-outs.


I think that it's a legitimate position to be opposed to a CoC like
this. I also think it's legitimate to feel so strongly about it, on
philosophical or political grounds, that you are compelled to avoid
participating while subject to the CoC. FWIW, the latter position
seems rather extreme to me personally, but I still respect it.


I understand it.

This:

https://marshmallow.readthedocs.io/en/dev/code_of_conduct.html

caused me to quit using Marshmallow in my projects.



In all sincerity, if you're compelled to walk away from participating
in mailing list discussions on a point of principle, then I wish you
well. That is your right.




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Vacuum not deleting tuples when lockless

[Martín Fernández]

Tom & Jerry,

Thanks a lot for information!

On Monday (weekends don't have the same load patterns compared to business 
days) I will take a look at ` pg_prepared_xacts` that seems to expose Jerry's 
suggestion on xacts. Replication slots don't apply to 9.2.X from what I could 
investigate so I will discard that suggestion. 

Feedback setting (hot_standby_feedback) is turned off in all our replicas, this 
shouldn't be an issue from what I understood. 

Delay setting (vacuum_defer_cleanup_age ) in our master is configured to 0, , 
this shouldn't be an issue from what I understood. 

Thanks a lot!

Best,
Martín

On Fri, Sep 14th, 2018 at 11:29 PM, Jerry Sievers  
wrote:

> 
> 
> 
> Tom Lane < t...@sss.pgh.pa.us > writes:
> 
> > =?UTF-8?q?Mart=C3=ADn_Fern=C3=A1ndez?= < fmarti...@gmail.com > writes:
> >
> >> We are experiencing some `vacuum` issues with a given table
> >> (potentially more). When a manual vacuum runs on the given table it
> >> seems that the `vacuum` process is not doing the expected cleanup.
> >
> >> DETAIL:  113257 dead row versions cannot be removed yet.
> >
> > Locks don't really have anything to do with that: what does matter is
> > how old is the oldest open transaction, because that determines the
> > "event horizon" that dead row versions have to fall below before they
> > can be removed. That oldest transaction might not be holding any locks
> > at the moment, but it doesn't matter, because in principle it could ask
> > to read this table later --- and it should see the table's contents as
> > of its snapshot.
> >
> > Serializable transactions are worse than repeatable-read transactions
> > for this purpose, because the former will keep a snapshot as of their
> > start time.
> >
> > As Jerry mentioned, replication slots can also act like open
> transactions
> > for this purpose, though I don't recall how much of that behavior is
> > present in 9.2.x.
> 
> Oops, didn't notice OP was on 9.2! Presume none, since I don't think we
> got rep slots till 9.4 :-)
> 
> >
> > regards, tom lane
> >
> >
> 
> --
> Jerry Sievers
> Postgres DBA/Development Consulting
> e: postgres.consult...@comcast.net
> p: 312.241.7800
> 
> 
> 
>

Re: Code of Conduct plan

[Tom Lane]

Martin Mueller  writes:
> Which makes me say again "Where is the problem that needs solving?"

We've re-litigated that point in each burst of CoC discussion for the
last two-plus years, I think.  But, one more time:

* So far as the mailing lists alone are concerned, we likely don't really
need a CoC; on-list incidents have been pretty few and far between.
However, there *have* been unfortunate incidents at conferences and in
other real-life contexts.  Core has been encouraging conference organizers
to create their own CoCs, but (a) they might want a model to follow;
(b) there needs to be a community-level backstop in case of failure of
a conference to have or enforce a CoC; and (c) conferences aren't the
only point of contact between community members.

* This isn't really directed at people who already participate in our
mailing lists.  The reason for setting up a formal CoC is to reassure
potential new contributors that the Postgres project offers a safe
environment for them.  As has been pointed out before, a lot of people
now feel that some sort of CoC is a minimum requirement for them to
want to deal with a community.  Whether you and I find that a bit too
shrinking-violety isn't relevant; if we want to keep attracting new
participants, we have to get with the program.

Now, the hazard in that of course is that someone will come in and
try to use the CoC mechanism to force the PG community to adopt that
person's standards of conduct.  It'll be up to the CoC committee
(and core, in the case of appeals) to say no, what you're complaining
about is well within this community's normal standards.  That's a
reason why a two-line CoC isn't a good idea; it leaves too much to
be read into it.

Anyway, the short answer here is that we've been debating CoC wording
for more than two years already, and it's time to stop debating and
just get it done.  We're really not going to entertain "let's rewrite
this completely" suggestions at this point.

regards, tom lane

Re: Code of Conduct plan

[Martin Mueller]

That is quite true: the very high quotient of helpful prose and very low 
quotient of inappropriate language is striking--much like the TEI list of which 
I long have been a member, and unlike the MySQL list, which has a non-trivial 
(though not serious)  boorish component. 

Which makes me say again "Where is the problem that needs solving?"

On 9/15/18, 11:32 AM, "Bruce Momjian"  wrote:

On Sat, Sep 15, 2018 at 04:24:38PM +, Martin Mueller wrote:
> What counts as foul language has changed a great deal in the last two 
decades. 
> You could always tie it to what is printable in the New York Times, but 
that
> too is changing. I could live with something like “Be considerate, and if 
you
> can’t be nice, be at least civil”.

I have to admit I am surprised how polite the language is here,
considering how crudely some other open source projects communicate.

-- 
  Bruce Momjian  
https://urldefense.proofpoint.com/v2/url?u=http-3A__momjian.us=DwIDaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk=TJILWn2nTs3E72LB1XpPNrNBCTYdMYWcTUevA54MIgM=jP360tfk8zSE3PhzhCJ5PSD_h8HnzqLCs4jFe5nUddE=
  EnterpriseDB 
https://urldefense.proofpoint.com/v2/url?u=http-3A__enterprisedb.com=DwIDaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk=TJILWn2nTs3E72LB1XpPNrNBCTYdMYWcTUevA54MIgM=EHp2yUxMzSrJsO0jCYJM4dq7m35j69Aec87OEBfXaP8=

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Code of Conduct plan

[Karsten Hilbert]

On Sat, Sep 15, 2018 at 12:11:37PM -0400, Melvin Davidson wrote:

> How about we just simplify the code of conduct to the following:
> Any member in the various PostgreSQL lists is expected to maintain
> respect to others and not use foul language. A variation from
> the previous sentence shall be considered a violation of the CoC.

That is, unfortunately, not possible, because "foul language"
is quite definitional to a large extent.

Functioning communities can usually intrinsically develop,
informally agree upon, and pragmatically enforce a workable
definition for themselves.

And often it will be extremely hard to *codify* such working
definitions to even remotely the same degree of success.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Re: Code of Conduct plan

[Bruce Momjian]

On Sat, Sep 15, 2018 at 04:24:38PM +, Martin Mueller wrote:
> What counts as foul language has changed a great deal in the last two 
> decades. 
> You could always tie it to what is printable in the New York Times, but that
> too is changing. I could live with something like “Be considerate, and if you
> can’t be nice, be at least civil”.

I have to admit I am surprised how polite the language is here,
considering how crudely some other open source projects communicate.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Code of Conduct plan

[Martin Mueller]

What counts as foul language has changed a great deal in the last two decades.  
You could always tie it to what is printable in the New York Times, but that 
too is changing. I could live with something like “Be considerate, and if you 
can’t be nice, be at least civil”.

From: Melvin Davidson 
Date: Saturday, September 15, 2018 at 11:12 AM
To: Tom Lane 
Cc: Bruce Momjian , Chris Travers , 
James Keener , Steve Litt , 
"pgsql-generallists.postgresql.org" 
Subject: Re: Code of Conduct plan

How about we just simplify the code of conduct to the following:
Any member in the various PostgreSQL lists is expected to maintain
respect to others and not use foul language. A variation from
the previous sentence shall be considered a violation of the CoC.

On Sat, Sep 15, 2018 at 11:51 AM Tom Lane 
mailto:t...@sss.pgh.pa.us>> wrote:
Bruce Momjian mailto:br...@momjian.us>> writes:
> There is a risk that if we adopt a CoC, and nothing happens, and the
> committee does nothing, that they will feel like a failure, and get
> involved when it was best they did nothing.  I think the CoC tries to
> address that, but nothing is perfect.

Yeah, a busybody CoC committee could do more harm than good.
The way the CoC tries to address that is that the committee can't
initiate action of its own accord: somebody has to bring it a complaint.

Of course, a member of the committee could go out and find a "problem"
and then file a complaint --- but then they'd have to recuse themselves
from dealing with that complaint, so there's an incentive not to.

regards, tom lane


--
Melvin Davidson
Maj. Database & Exploration Specialist
Universe Exploration Command – UXC
Employment by invitation only!

Re: Code of Conduct plan

[Melvin Davidson]

How about we just simplify the code of conduct to the following:
Any member in the various PostgreSQL lists is expected to maintain
respect to others and not use foul language. A variation from
the previous sentence shall be considered a violation of the CoC.


On Sat, Sep 15, 2018 at 11:51 AM Tom Lane  wrote:

> Bruce Momjian  writes:
> > There is a risk that if we adopt a CoC, and nothing happens, and the
> > committee does nothing, that they will feel like a failure, and get
> > involved when it was best they did nothing.  I think the CoC tries to
> > address that, but nothing is perfect.
>
> Yeah, a busybody CoC committee could do more harm than good.
> The way the CoC tries to address that is that the committee can't
> initiate action of its own accord: somebody has to bring it a complaint.
>
> Of course, a member of the committee could go out and find a "problem"
> and then file a complaint --- but then they'd have to recuse themselves
> from dealing with that complaint, so there's an incentive not to.
>
> regards, tom lane
>
>

-- 
*Melvin Davidson*
*Maj. Database & Exploration Specialist*
*Universe Exploration Command – UXC*
Employment by invitation only!

Re: Code of Conduct plan

[Tom Lane]

Bruce Momjian  writes:
> There is a risk that if we adopt a CoC, and nothing happens, and the
> committee does nothing, that they will feel like a failure, and get
> involved when it was best they did nothing.  I think the CoC tries to
> address that, but nothing is perfect.

Yeah, a busybody CoC committee could do more harm than good.
The way the CoC tries to address that is that the committee can't
initiate action of its own accord: somebody has to bring it a complaint.

Of course, a member of the committee could go out and find a "problem"
and then file a complaint --- but then they'd have to recuse themselves
from dealing with that complaint, so there's an incentive not to.

regards, tom lane

Re: Code of Conduct plan

[Bruce Momjian]

On Sat, Sep 15, 2018 at 11:32:06AM -0400, Bruce Momjian wrote:
> There is a risk that if we adopt a CoC, and nothing happens, and the
> committee does nothing, that they will feel like a failure, and get
> involved when it was best they did nothing.  I think the CoC tries to
> address that, but nothing is perfect.

I think this is Parkinson's law:

https://en.wikipedia.org/wiki/Parkinson%27s_law

We might want to put something in the next draft CoC saying that the
committee is a success if it does nothing.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Code of Conduct plan

[Bruce Momjian]

On Sat, Sep 15, 2018 at 08:44:10AM +0200, Chris Travers wrote:
> The protection there is a culturally diverse code of conduct committee who can
> then understand the relationship between politics and culture.  And just to
> note, you can't solve problems of abuse by adopting mechanistically applied
> rules.
> 
> Also a lot of the major commercial players have large teams in areas where
> there is a legal right to not face discrimination on the basis of political
> opinion.  So I don't see merely expressing an unpopular political opinion as
> something the code of conduct committee could ever find actionable, nor do I
> think political donations or membership in political or religious 
> organizations
> etc would be easy to make actionable.

Well, we could all express our unpopular opinions on this channel and
give it a try.  ;-)  I think some have already, and nothing has happened
to them.  With a CoC, I assume that will remain true.

> But I understand the sense of insecurity.  Had I not spent time working in 
> Asia
> and Europe, my concerns would be far more along these lines.  As it is, I 
> don't
> think the code of conduct committee will allow themselves to be used to cause
> continental splits in the community or to internationalize the politics of the
> US.

Agreed, and that is by design.  If anything, the CoC team plus the core
team have even more diversity than the core team alone.

> I think the bigger issue is that our community *will* take flak and possibly 
> be
> harmed if there is an expectation set that picking fights in this way over
> political opinions is accepted.  Because while I don't see the current
> community taking action on the basis of political views, I do see a problem
> more generally with how these fights get picked and would prefer to see some
> softening of language to protect the community in that case.  But again, I am
> probably being paranoid.

Well, before the CoC, anything could have happened since there were no
rules at all about how such problems were handled, or not handled. 

There is a risk that if we adopt a CoC, and nothing happens, and the
committee does nothing, that they will feel like a failure, and get
involved when it was best they did nothing.  I think the CoC tries to
address that, but nothing is perfect.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Query act different when doing by hand and by using a driver in app

[ik]

Hi

Thank you for the answer, after a longer tracing, (go based and printing pg
queries to log, I realize that it happens on a different place that I
thought it does.

Ido

On Sat, Sep 15, 2018 at 12:13 AM Adrian Klaver 
wrote:

> On 9/14/18 12:11 PM, ik wrote:
> > Hello,
> >
> > Not sure that this is the right mailing list, so sorry from advance.
> >
> > I have a program that when it does a query I have one raw returns, but
> > when I execute the same query with the same conditions, I get the right
> > number of rows back.
>
> The above is going to need more information to work out:
>
> 1) The query that returns one row is running in a Go program using the
> Go driver below, correct?
>
> 2) The other query that returns correctly is being run where and how?
>
> 3) What is the actual query?
>
> 4) How is the query setup in the program?
>
> 5) Are you sure the incorrect and correct queries are running against
> the same database?
>
> >
> > I'm using gonlang and https://github.com/jackc/pgx .
> > The query inside is inside an already open cursor of another "select"
> > query that I iterate over.
> >
> > Is there a way to debug just that inside pg-logs without having all
> > possible queries logged in?
>
> If it is a SELECT query then no.
>
> >
> > Thank you
> > Ido
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Code of Conduct plan

[Olivier Gautherot]

Dear all,

On Fri, Sep 14, 2018 at 5:18 PM Tom Lane  wrote:

> Robert Haas  writes:
> > It's not clear to me that there IS a general consensus here.  It looks
> > to me like the unelected core team got together and decided to impose
> > a vaguely-worded code of conduct on a vaguely-defined group of people
> > covering not only their work on PostgreSQL but also their entire life.
>
> There's been quite a lot of input, from quite a lot of people, dating
> back at least as far as a well-attended session at PGCon 2016.  I find
> it quite upsetting to hear accusations that core is imposing this out
> of nowhere.  From my perspective, we're responding to a real need
> voiced by other people, not so much by us.
>
> > However, I also don't think it matters very much.
>
> Yeah, this.  The PG community is mostly nice people, AFAICT.  I'll be
> astonished (and worried) if the CoC committee finds much to do.  We're
> implementing this mostly to make newcomers to the project feel that
> it's a safe space.
>
> It's also worth reminding people that this is v1.0 of the CoC document.
> We plan to revisit it in a year or so, and thereafter as needed, to
> improve anything that's causing problems or not working well.
>
> regards, tom lane
>

I must admit that I'm impressed by the huge amount of contributions to this
thread and, to be honest, it is the only one I have witnessed that would
have deserved a CoC. I had a quick look at the proposal and it sounds to me
like the team is trying to handle excesses - as long as no one complains, I
would bet that they won't even chime in.

One thing to keep in mind is this simple definition: "One person's freedom
ends where another's begins" and all the work should go in this direction.
We are all different, have different sensitivities, come from different
cultures where we interpret words in a different way - it's a given, no way
to escape. But we have in common the love of a great piece of software
provided by a very active and efficient community.

Why don't we focus on what unites us, instead of what creates divisions?

Have a peaceful week-end
Olivier

column information from view

[Seb]

Hello,

I'm trying to generate a table with information from a temporary view
that simply selects a subset of columns from a persistent view in a
given schema.  The persistent view joins a number of tables with columns
that may or may not have a description entered.

Here's my attempt at listing the temporary view's columns and respective
descriptions:

SELECT cols.ordinal_position, cols.column_name,
  col_description(cl.oid, cols.ordinal_position::INT)
FROM pg_class cl, information_schema.columns cols
WHERE cols.table_catalog='dbname' AND cols.table_schema='some_schema' AND
  cols.table_name = 'persistent_view' AND cols.table_name = cl.relname
ORDER BY cols.ordinal_position::INT;

The problem with this one, of course, is that it lists *all* columns
from the persistent view, instead of the subset of them in the temporary
view.  Is there a better way to do that?

Thanks,
-- 
Seb

Re: Bitmap Heap Scan and Bitmap Index Scan

[Pavel Stehule]

Hi

so 15. 9. 2018 v 9:39 odesílatel Arup Rakshit  napsal:

> Here is a explain plan of a very simple query:
>
> aruprakshit=# explain analyze select first_name, last_name from users
> where lower(state) = 'colorado';
> QUERY PLAN
>
> --
>  Bitmap Heap Scan on users  (cost=5.86..161.40 rows=203 width=13) (actual
> time=0.134..0.444 rows=203 loops=1)
>Recheck Cond: (lower((state)::text) = 'colorado'::text)
>Heap Blocks: exact=106
>->  Bitmap Index Scan on lower_state_users_idx  (cost=0.00..5.81
> rows=203 width=0) (actual time=0.098..0.098 rows=203 loops=1)
>  Index Cond: (lower((state)::text) = 'colorado'::text)
>  Planning time: 0.263 ms
>  Execution time: 0.517 ms
> (7 rows)
>
> I read this
> https://www.postgresql.org/message-id/12553.1135634231%40sss.pgh.pa.us
> 
>  and
> https://www.postgresql.org/message-id/464F3C5D.2000700%40enterprisedb.com
>   to
> understand what this bitmap heap scan and index scan is. But there are some
> questions still in mind which I am not able to figure out yet.
>
> Does bitmap index apply when normal index scan is costly?
>

yes

Does bitmap index always store page number of matching tuples instead of
> just the tuples?
>

What I know, it doesn't store tuples - if there are good enough memory,
then tid are stored (page number, tuple number), else only page numbers are
stored.


> What is Heap Blocks: exact=106 ?
>

see
https://paquier.xyz/postgresql-2/postgres-9-4-feature-highlight-lossyexact-pages-for-bitmap-heap-scan/

Why the cost is higher in Heap scan than index scan?
>

It have to read all pages, but depends on hw and configuration, this read
can be fast

Regards

Pavel


> Thanks,
>
> Arup Rakshit
> a...@zeit.io
>
>
>
>

Bitmap Heap Scan and Bitmap Index Scan

[Arup Rakshit]

Here is a explain plan of a very simple query:

aruprakshit=# explain analyze select first_name, last_name from users where 
lower(state) = 'colorado';
QUERY PLAN
--
 Bitmap Heap Scan on users  (cost=5.86..161.40 rows=203 width=13) (actual 
time=0.134..0.444 rows=203 loops=1)
   Recheck Cond: (lower((state)::text) = 'colorado'::text)
   Heap Blocks: exact=106
   ->  Bitmap Index Scan on lower_state_users_idx  (cost=0.00..5.81 rows=203 
width=0) (actual time=0.098..0.098 rows=203 loops=1)
 Index Cond: (lower((state)::text) = 'colorado'::text)
 Planning time: 0.263 ms
 Execution time: 0.517 ms
(7 rows)

I read this 
https://www.postgresql.org/message-id/12553.1135634231%40sss.pgh.pa.us 
 and 
https://www.postgresql.org/message-id/464F3C5D.2000700%40enterprisedb.com 
  to 
understand what this bitmap heap scan and index scan is. But there are some 
questions still in mind which I am not able to figure out yet.

Does bitmap index apply when normal index scan is costly?
Does bitmap index always store page number of matching tuples instead of just 
the tuples?
What is Heap Blocks: exact=106 ?
Why the cost is higher in Heap scan than index scan?

Thanks,

Arup Rakshit
a...@zeit.io

Re: Code of Conduct plan

[Chris Travers]

On Sat, Sep 15, 2018 at 4:47 AM James Keener  wrote:

>
>
> The preceding's pretty simple. An attacker goes after an individual,
>> presumably without provocation and/or asymetrically. The attacked
>> person is on this mailing list. IMHO this attacker must choose between
>> continuing his attacks, and belonging to the Postgres community.
>>
>> What's tougher is the person who attacks groups of people.
>>
>>
> The preceding's pretty simple. An "attacker" voices their political
> opinions
> or other unorthodoxy or unpopular stance, but in no way directs it at the
> postgres user base or on a postgres list. The "attacked"
> person is on this mailing list. IMHO this "attacker" must choose between
> continuing to voice their opinion, and belonging to the Postgres community.
>

The protection there is a culturally diverse code of conduct committee who
can then understand the relationship between politics and culture.  And
just to note, you can't solve problems of abuse by adopting mechanistically
applied rules.

Also a lot of the major commercial players have large teams in areas where
there is a legal right to not face discrimination on the basis of political
opinion.  So I don't see merely expressing an unpopular political opinion
as something the code of conduct committee could ever find actionable, nor
do I think political donations or membership in political or religious
organizations etc would be easy to make actionable.

But I understand the sense of insecurity.  Had I not spent time working in
Asia and Europe, my concerns would be far more along these lines.  As it
is, I don't think the code of conduct committee will allow themselves to be
used to cause continental splits in the community or to internationalize
the politics of the US.

I think the bigger issue is that our community *will* take flak and
possibly be harmed if there is an expectation set that picking fights in
this way over political opinions is accepted.  Because while I don't see
the current community taking action on the basis of political views, I do
see a problem more generally with how these fights get picked and would
prefer to see some softening of language to protect the community in that
case.  But again, I am probably being paranoid.

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more