Re: [GENERAL] Uber migrated from Postgres to MySQL

[James Keener]

If we're talking about favourite bug https://bugs.mysql.com/bug.php?id=21153
is mine

Join with many tables hangs mysql (and taking 100% cpu)
> Description:
> the following query hangs the mysql server taking 100% cpu. also an
> "explain" of the query hangs the server!


It's "not a bug" because you can change some of the default query planning
parameters to avoid it:

Igor Babaev
> This is not a bug.
> The reported query is a 18-way join. For such queries we expect that the
> full search for the best execution plan will take a significant amount of
> time.
> At the same due to a specific structure of the reported query we can hope
> to get a good execution plan with a limited search (see Manual 5.0: 7.5.3.
> Controlling Query Optimizer Performance).
> Setting the value of the global variable 'optimizer_search_depth' to 4 or
> even to 2 we can get the same execution plan as with a full search. Yet it
> will take much less time:


To me that speaks volumes. Sure, you can tweak a db params to get better
performance, but I shouldn't have to deviate from the default for it to
simply work at all!

Jim

On Thu, Jul 28, 2016 at 9:38 AM, Scott Marlowe 
wrote:

> On Wed, Jul 27, 2016 at 9:51 AM, Geoff Winkless 
> wrote:
> > On 27 July 2016 at 15:22, Scott Mead  wrote:
> >>
> >>  "The bug we ran into only affected certain releases of Postgres 9.2 and
> >> has been fixed for a long time now. However, we still find it worrisome
> that
> >> this class of bug can happen at all. A new version of Postgres could be
> >> released at any time that has a bug of this nature, and because of the
> way
> >> replication works, this issue has the potential to spread into all of
> the
> >> databases in a replication hierarchy."
> >>
> >>
> >> ISTM that they needed a tire swing and were using a dump truck.
> Hopefully
> >> they vectored somewhere in the middle and got themselves a nice sandbox.
> >
> >
> > At least his bug got fixed. The last 2 bugs I reported to MySQL resulted
> in
> > an initial refusal to accept any problem existed, followed by (once that
> > particular strategy had run out of steam) the developer simply ignoring
> the
> > bug until it was closed automatically by their bug system. As far as I'm
> > aware those bugs still exist in the most recent version.
>
> Best / worst MySQL bug was one introduced and fixed twice. Someone put
> in a short cut that sped up order by by quite a bit. It also meant
> that order by desc would actually get order by asc output. It was
> inserted into the code due to poor oversite / code review practices,
> then fixed about 9 months later, then introduced again, and again,
> took about a year to fix.
>
> The fact that it was introduced into a General Release mid stream with
> no testing or real reviews speaks volumes about MySQL and its
> developers. The fact that it took months to years to fix each time
> does as well.
>
> As someone who has gotten more than one bug fix from pgsql in less
> than 48 hours, I feel sorry for anyone who finds a bug in a MySQL
> version they are running in production.
>
>
> --
> 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] Uber migrated from Postgres to MySQL

[James Keener]

So, millions is a lot, but it's not difficult to get to a place where
you have thousands or tables.

Image a case in which census data and the associated geometries.
https://github.com/censusreporter/census-postgres has 22 surveys, each
with 230+ tables. That's 5000+ tables right there.  Now, the TIGER
tables for all of that is another 50 tables per year, so another 350
tables.

If these were to be partitioned by state, instead of all records for
all states in a single table, then we're looking at 270,000.

Jim

On Thu, Jul 28, 2016 at 12:48 AM, John R Pierce  wrote:
> On 7/27/2016 9:39 PM, Jeff Janes wrote:
>>
>> That depends on how how many objects there are consuming that 1 TB.
>> With millions of small objects, you will have problems.  Not as many
>> in 9.5 as there were in 9.1, but still it does not scale linearly in
>> the number of objects.  If you only have thousands of objects, then as
>> far as I know -k works like a charm.
>
>
> millions of tables?  thats akin to having millions of classes in an object
> oriented program, seems a bit excessive.
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


-- 
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] GRANTable Row Permissions

[James Keener]

Of course I think of something as soon as I send it.  Policies can be
granted to a specific role! So

   create policy xx on table_1 for select to role_1 using (row_id = 1234);

Jim

On Sun, Jul 3, 2016 at 12:26 PM, James Keener  wrote:
> I'm trying to work out how to grant permissions to rows in a table
> without having to rebuild the pg auth mechanisms (see below). One option
> is to have many tables (each representing a row), and grant normally.
> The other is, like I build below, uses a table and a recursive CTE to
> resolve the PG group membership and apply it to the table in question
> using a RLS policy.  Is any of this sane?
>
> So, aay I have
>
> create table viz (
> viz_id bigserial primary key,
> name text
> );
>
> create role group_a;
> create role group_b;
> create role user1;
> create role user2;
> create role user3;
>
> grant group_a to user1;
> grant group_b to group_a;
>
> insert into viz (name) values ('test 1'),('test 2'),('test 3');
>
>
>
> I am trying to find a way to essentially do the following:
>
> revoke select on viz from public;
> grant select on viz to group_a where viz_id = 1;
> grant select on viz to user2 where viz_id = 2;
> grant select on viz to group_b where viz_id = 3;
>
> With RLS I can create a policy that can validate via an arbitrary sql
> statement, but I can't think of a clean way to have row-level grants
> that can be implemented without having to kludge the pg permission
> system into a table.  The following kind of gets at what I want, but
> uses a table instead of being able to grant.
>
> create table viz_perm (
> viz_id bigint references viz,
> role_name text,
> can_view boolean not null default false
> );
>
> alter table viz enable row level security;
> alter table viz_perm enable row level security;
>
> create policy viz_permissions on viz_perm for select using (
> (with recursive rec_roles(grantee,granted) as (
> select roless.rolname as grantee, groupss.rolname as granted
> from pg_roles roless
> inner join pg_auth_members
> on roless.oid = pg_auth_members.member
> inner join pg_roles groupss
> on groupss.oid = pg_auth_members.roleid
> union
> select rec_roles.grantee as grantee, groupss.rolname as granted
> from rec_roles
> inner join pg_roles roless on roless.rolname = rec_roles.granted
> inner join pg_auth_members
> on roless.oid = pg_auth_members.member
> inner join pg_roles groupss
> on groupss.oid = pg_auth_members.roleid
> )
> select bool_or(true)
> from rec_roles
> where
> role_name = current_user
>  or (grantee = current_user and granted = role_name))
> );
>
>  create policy viz_permissions on viz using (
>  (select bool_or(can_view)
>   from viz_perm
>   where viz_perm.viz_id=viz.viz_id)
>  );
>
> insert into viz_perm (viz_id, role_name, can_view) values
> (1, 'group_a', true),
> (2, 'user2',   true),
> (3, 'group_b', true);
>
> grant select on viz to user1;
> grant select on viz_perm to user1;
> grant select on viz to user2;
> grant select on viz_perm to user2;
>
>
> set role user1;
> select * from viz;
> -- viz_id |  name
> --+
> --  1 | test 1
> --  3 | test 3
> --(2 rows)
>
> reset role;
> set role user2;
> select * from viz;
> -- viz_id |  name
> --+
> --  2 | test 2
> --(1 row)
>
> reset role;
>
> While the above more-or-less works, it feels very wonky.  Is there a
> better way to do this? Would it be better to have a table for each viz,
> necessitating each table having a single row, and using the standard
> permission system.  Is what I describe and build in this email an
> acceptable way to go about doing what I want to do?
>
> Thanks,
> Jim


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

[GENERAL] GRANTable Row Permissions

[James Keener]

I'm trying to work out how to grant permissions to rows in a table
without having to rebuild the pg auth mechanisms (see below). One option
is to have many tables (each representing a row), and grant normally.
The other is, like I build below, uses a table and a recursive CTE to
resolve the PG group membership and apply it to the table in question
using a RLS policy.  Is any of this sane?

So, aay I have

create table viz (
viz_id bigserial primary key,
name text
);

create role group_a;
create role group_b;
create role user1;
create role user2;
create role user3;

grant group_a to user1;
grant group_b to group_a;

insert into viz (name) values ('test 1'),('test 2'),('test 3');



I am trying to find a way to essentially do the following:

revoke select on viz from public;
grant select on viz to group_a where viz_id = 1;
grant select on viz to user2 where viz_id = 2;
grant select on viz to group_b where viz_id = 3;

With RLS I can create a policy that can validate via an arbitrary sql
statement, but I can't think of a clean way to have row-level grants
that can be implemented without having to kludge the pg permission
system into a table.  The following kind of gets at what I want, but
uses a table instead of being able to grant.

create table viz_perm (
viz_id bigint references viz,
role_name text,
can_view boolean not null default false
);

alter table viz enable row level security;
alter table viz_perm enable row level security;

create policy viz_permissions on viz_perm for select using (
(with recursive rec_roles(grantee,granted) as (
select roless.rolname as grantee, groupss.rolname as granted
from pg_roles roless
inner join pg_auth_members
on roless.oid = pg_auth_members.member
inner join pg_roles groupss
on groupss.oid = pg_auth_members.roleid
union
select rec_roles.grantee as grantee, groupss.rolname as granted
from rec_roles
inner join pg_roles roless on roless.rolname = rec_roles.granted
inner join pg_auth_members
on roless.oid = pg_auth_members.member
inner join pg_roles groupss
on groupss.oid = pg_auth_members.roleid
)
select bool_or(true)
from rec_roles
where
role_name = current_user
 or (grantee = current_user and granted = role_name))
);

 create policy viz_permissions on viz using (
 (select bool_or(can_view)
  from viz_perm
  where viz_perm.viz_id=viz.viz_id)
 );

insert into viz_perm (viz_id, role_name, can_view) values
(1, 'group_a', true),
(2, 'user2',   true),
(3, 'group_b', true);

grant select on viz to user1;
grant select on viz_perm to user1;
grant select on viz to user2;
grant select on viz_perm to user2;


set role user1;
select * from viz;
-- viz_id |  name
--+
--  1 | test 1
--  3 | test 3
--(2 rows)

reset role;
set role user2;
select * from viz;
-- viz_id |  name
--+
--  2 | test 2
--(1 row)

reset role;

While the above more-or-less works, it feels very wonky.  Is there a
better way to do this? Would it be better to have a table for each viz,
necessitating each table having a single row, and using the standard
permission system.  Is what I describe and build in this email an
acceptable way to go about doing what I want to do?

Thanks,
Jim


-- 
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] PostgresSQL and HIPAA compliance

[James Keener]

The method you use to store the data is irrelevant. Access to your network.
Logging. If you're encrypting the disk. How is the application presenting
this data. What kind of ACLs are you using. Asking if PG is good to store
HIPAA data is exactly as useful as asking if you can even store HIPAA data.
There are so many more important things to consider.

RDS is a hosted service. They don't have all the guarentees you'd  want for
PHI. I'm sure they're MySQL engine probably has similar warnings.

Jim

On Fri, Jun 17, 2016 at 6:03 AM, Alex John  wrote:

> Hello, I have a few questions regarding the use of PostgreSQL and HIPAA
> compliance. I work for a company that plans on storing protected health
> information (PHI) on our servers. We have looked at various solutions for
> doing
> so, and RDS is a prime candidate except for the fact that they have
> explicitly
> stated that the Postgres engine is *not* HIPAA compliant.
>
> Users on the IRC channel generally say that the guidelines are more catered
> towards building better firewalls and a sane access policy, but I would
> like to
> know if there is anything within the implementation of Postgres itself that
> violates said compliance.
>
> If anyone works at a similar company and utilizes postgresql to store PHI,
> please let me know.
>
> Thank you,
>   Alex
>
> --
> 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] Unique UUID value - PostgreSQL 9.2

[James Keener]

Is a uuid a valid value in the application making use of the data? Why can't 
you add the column to table b and then import, or use create the uuid in the 
import select clause? I'm also having trouble understanding the problem and why 
you've discounted the options you've not even told us you've considered.

On March 14, 2016 5:37:00 PM EDT, "drum.lu...@gmail.com"  
wrote:
>On 15 March 2016 at 10:29, David G. Johnston
>
>wrote:
>
>> On Mon, Mar 14, 2016 at 2:13 PM, drum.lu...@gmail.com <
>> drum.lu...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>
>> favorite
>>>
>
>>>
>>> I've got 2 tables:
>>>
>>> Temp-Table
>>> Table-A
>>>
>>> Need to copy all the data from *Temp-Table* to *Table-A*. But there
>is a
>>> Constraint that does not allow me to have duplicated items.
>>>
>>> So I need to create a Unique value.
>>>
>>> *Example:*
>>>
>>> Column Code|   Column Info   |
>>> code_67493675936info_2016
>>>
>>> *Question:*
>>>
>>> How can I do that using PostgreSQL 9.2?
>>>
>>
>> You might want to try to restate the problem and question.  I'm
>having a
>> hard time trying to figure out what you want.
>>
>> Reading your subject line I'll point you to:
>>
>> http://www.postgresql.org/docs/9.2/interactive/datatype-uuid.html
>>
>> specifically the extension that is mentioned.
>>
>> ​Usually people figure out ways to accomplish their goals without
>using
>> UUID though.
>>
>> David J.
>> ​
>>
>>
>I want to import data from table A to table B, but when doing it the
>column
>"code" on table B has to have some unique random data.
>
>I could use UUID like:
>insert into "TB" ("Id", "Title") values (uuid_generate_v4(), '111');
>
>but I'm doing:
>INSERT INTO tableb (SELECT * FROM TABLEA)
>
>So, how to use UUID using the SELECT above?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] BDR

[James Keener]

Also, what did you run exactly (sanitized of course).

On March 14, 2016 5:38:19 PM EDT, John R Pierce  wrote:
>On 3/14/2016 2:17 PM, Dustin Kempter wrote:
>> However my instances are not on the same server and I attempted to 
>> simply add a host=(the ip) but that failed. Please help 
>
>did you get an error?   if so what error, exactly?
>
>
>
>-- 
>john r pierce, recycling bits in santa cruz
>
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] retrieve grouping sets/rollup rows

[James Keener]

/me has learned something new!

Thanks!


On 03/13/2016 10:44 PM, Tom Lane wrote:
>>> On 03/13/2016 10:07 PM, Tom Smith wrote:
 It would help if the resultset has some param to mark which is which
 with the grouping sets index.
> 
> I think you're looking for the GROUPING() function.  See
> http://www.postgresql.org/docs/9.5/static/functions-aggregate.html
> 
>   regards, tom lane
> 


-- 
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] retrieve grouping sets/rollup rows

[James Keener]

It just dawned on me that you may note have meant having them in a
specific sequence in the result set.  Even still, I think it's much more
clear being explicit with what rows are included and which aren't.

Jim

On 03/13/2016 10:12 PM, James Keener wrote:
> Why? You're already provided with this information: NULL fields are not
> being used in the grouping set for the row. Moreover, it would seem to
> be an implementation- and run-time- dependent value, as there is no
> reason group by grouping set (a,b), (c,d) couldn't be executed in
> written order, or (c,d) first depending on a lot of things.
> 
> Forcing the implementation to conform to a certain way of doing things
> is asking for someone to ask why a certain optimization isn't being
> performed later on.
> 
> My $0.02.
> 
> Jim
> 
> On 03/13/2016 10:07 PM, Tom Smith wrote:
>> It would help if the resultset has some param to mark which is which
>> with the grouping sets index.
>> for example, the results for (a,b,c,d) would be marked as for index =0, 
>> (b,c,d) would be index=1
>>
>> On Sun, Mar 13, 2016 at 9:52 PM, James Keener > <mailto:j...@jimkeener.com>> wrote:
>>
>> Do you want to know if a row is from the (a,b) or (c,d) group?  All rows
>> will contain (a,b,c,d) but (a,b) will be NULL for the (c,d) grouping
>> sets, and vice-versa.
>>
>> Jim
>>
>> On 03/13/2016 09:45 PM, Tom Smith wrote:
>> > Hello:
>> >
>> > With JDBC, how can I tell which row is for which grouping sets or
>> rollup
>> > using result sets
>> >
>> > Thanks
>> >
>> >
>>
>>


-- 
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] retrieve grouping sets/rollup rows

[James Keener]

Why? You're already provided with this information: NULL fields are not
being used in the grouping set for the row. Moreover, it would seem to
be an implementation- and run-time- dependent value, as there is no
reason group by grouping set (a,b), (c,d) couldn't be executed in
written order, or (c,d) first depending on a lot of things.

Forcing the implementation to conform to a certain way of doing things
is asking for someone to ask why a certain optimization isn't being
performed later on.

My $0.02.

Jim

On 03/13/2016 10:07 PM, Tom Smith wrote:
> It would help if the resultset has some param to mark which is which
> with the grouping sets index.
> for example, the results for (a,b,c,d) would be marked as for index =0, 
> (b,c,d) would be index=1
> 
> On Sun, Mar 13, 2016 at 9:52 PM, James Keener  <mailto:j...@jimkeener.com>> wrote:
> 
> Do you want to know if a row is from the (a,b) or (c,d) group?  All rows
> will contain (a,b,c,d) but (a,b) will be NULL for the (c,d) grouping
> sets, and vice-versa.
> 
> Jim
> 
> On 03/13/2016 09:45 PM, Tom Smith wrote:
> > Hello:
> >
> > With JDBC, how can I tell which row is for which grouping sets or
> rollup
> > using result sets
> >
> > Thanks
> >
> >
> 
> 


-- 
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] retrieve grouping sets/rollup rows

[James Keener]

Do you want to know if a row is from the (a,b) or (c,d) group?  All rows
will contain (a,b,c,d) but (a,b) will be NULL for the (c,d) grouping
sets, and vice-versa.

Jim

On 03/13/2016 09:45 PM, Tom Smith wrote:
> Hello:
> 
> With JDBC, how can I tell which row is for which grouping sets or rollup
> using result sets
> 
> Thanks
> 
> 


-- 
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] PostgreSQL 9.5 and process REST calls enquiry

[James Keener]

>
>
> https://github.com/begriffs/postgrest also looks interesting!
>>
>
> I thought the purpose of Spring/Spring Boot was to provide the REST
> services in front of your choice of data store. Not sure how putting
> another server in the stack is going to help things.


I was simply responding to the original question about accessing the DB
over HTTP.

Re: [GENERAL] PostgreSQL 9.5 and process REST calls enquiry

[James Keener]

https://github.com/begriffs/postgrest also looks interesting!

On Fri, Feb 12, 2016 at 10:24 AM, Adrian Klaver 
wrote:

> On 02/12/2016 03:00 AM, Peter van Eck wrote:
>
>>
>>
>> Hi, We are looking into setting up a PostgreSQL environment for an
>> application that inputs JSON through via http rest calls.
>>
>> Now that we havent been using Postgres for these kind of setups I was
>> wondering what the course of action is in setting this up.
>>
>> The development team is coding this in srpingboot with an embedded
>> mongodb version. Do we have to configure pgrest for instance to enable
>> postgres for processing JSON rest calls via HTTP or is that not necessary
>> ?
>> Again just puzzling in how to approach this...
>>
>
> The below looks like a good start:
>
>
> http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-sql.html
>
>
>>
>> thanks in advance.
>>
>> Peter
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
>
> --
> 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] WIP: CoC

[James Keener]

>
>
> https://modelviewculture.com/pieces/codes-of-conduct-when-being-excellent-is-not-enough
>
That post seems to discuss why a written CoC is needed (as opposed to an
unwritten "act professional" one). I don't believe it applies to my
comment.

Re: [GENERAL] Code of Conduct: Is it time?

[James Keener]

This line has already been substantially changes. Can we keep discussion of the 
language of the WIP in the thread meant for it? This way people don't waste 
time discussing language which no longer exists.

Jim

On January 12, 2016 9:17:55 AM EST, Neil Tiffin  wrote:
>
>> On Jan 12, 2016, at 7:50 AM, Vick Khera  wrote:
>> 
>> On Mon, Jan 11, 2016 at 6:55 PM, Steve Litt
> wrote:
>>> All because somebody just *had* to personally insult someone else,
>>> repeatedly, and nobody thought that was a bad thing, and when the
>>> recipient finally objected, the objection was chalked up to him or
>her
>>> valuing his/her victimhood.
>> 
>> +1
>> 
>> I was thinking along the same lines when I saw JD's original list
>> containing that "victimhood" line. I think that one line pretty much
>> eviscerates the entire purpose of having the CoC.
>> 
>
>I don’t remember the “victimhood” line, but it is important to make
>sure people understand that the problem manifests itself both by being
>to sensitive by the complainer and not being sensitive enough by the
>group. I do believe that in any document it needs to be stated that
>everyone is expected to be tolerant of others.  A free society cannot
>exist without some level of tolerance.
>
>Neil 
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

[James Keener]

Wow. I mean actually wow.

So many things. Just so many.

You still haven't explained why core contributors need to be treated like 
special snowflakes. If someone acts inappropriately then they should be told 
so, regardless of status. Why should we protect anyone in the wrong? 

Moreover, your scenario is so contrived and actually ends in a situation which 
supports my point, not yours.

I don't understand your point and you never clarify it. Why does how technical 
decisions are made affect how each person is suppose to treat each other 
person? We won't look past a core contributor being an ass, nor should we 
accept attacks because someone doesn't like technical decisions. None of this 
actually matters as it's all covered inside a more general CoC.

I don't want a contrived example that backs up my argument, I want you to point 
out at where my assumptions (everyone should be excellent to one another, as 
defined in a general CoC) or my chain of reasoning (core contributors are part 
of everyone, therefore interactions with and by them are covered under a 
general CoC).

"THE END" is also the most childish way to claim you're incapable of actually 
defending your argument and just want to declare yourself the winner. I'm sorry 
you don't enjoy this discussion. You're free to leave it if you wish.

Jim

On January 12, 2016 9:07:08 AM EST, Regina Obe  wrote:
>>  If the attacker goes public, we point people at the exchange that
>happened where Tom has presumably already discussed the reasons that
>the patch/feature/&c isn't being accepted.
>
>If someone wanted to out someone, they would study them carefully. 
>They would find Tom's buttons and push them.
>They will show proof of Tom saying fuck you trans thing (probably
>something worse) and all that and it would  be a bad reflection on Tom
>and our community.
>It's because they don't have a Coc that Tom is such a jerk.  They let
>the power get to his head.
>They would have proof is my point in an email trail.  
>
>Luckily I think Tom doesn't have many visible buttons to push, but
>others in our community do.
>Anyrate I think it's looking more like a Coc will hurt us more than do
>us good.  This is beginning to feel too much like Highschool
>Lincoln-douglass debating which I never enjoyed.
>I just want to get back to programming something useful.
>
>
>> I don't think I understand your point. So I get 100 friends to come
>here and ask for Tom to be outed, we ask for the reason and when they
>don't produce a valid one, nothing happens because none of us have any
>power.
>They will ask, they'll point at a random link.  Like this one - 
>https://twitter.com/krainboltgreene/status/611569515315507200
>
>You'll be too lazy to read it and assume they read it and they are
>right.  Tom will be persecuted for some link everyone was too lazy to
>read.
>News of Tom's jerkiness would spread across the internet like a virus. 
>
>The jerk think would be echoed by everyone until everyone believes it
>and takes it to heart. "Tom is a big jerk. How can the PostgreSQL
>project allow such a jerk to be running the show."
>Tom will feel bad and think - "No good deed goes unpunished", he'll
>step down.
>
>THE END
>
>
>Thanks,
>Regina

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

[James Keener]

>> That has nothing to do with the Code of Conduct, though.
>> The community accepting Tom saying "no" to Feature X is
>> vastly different than the community not calling Tom out
>> for being mean.
>> The CoC is about the later situation and not the prior;
>> and the community should call Tom out. (I'm sure you're
>> a great person, Tom, sorry you're the example being used
>> here.)
> 
> Let me reiterate that YES it does.  The reason is that this
> is a Contributor Code of Conduct, so covers whether and how
> you accept a piece of code.

No, no it's not. It's about interpersonal interactions, not technical
decisions.

> In certain gang of 10 that has not contributed anything to our
> project can argue that you took person X over person Y's
> implementation because person Y is black and you are racist.
> If everyone is equal -- how are you going to fight that?

The same way I would argue with you if you called me sexist for not
liking your ideas? I'm not understanding your point. Why is this any
different than someone calling someone else a racist? The project
backing Tom's decision has nothing to do with responding to Tom being
called a racist. Moreover if the project backs Tom's decision on a
technical basis, the attacker isn't going to get very far with relief
here. If the attacker goes public, we point people at the exchange that
happened where Tom has presumably already discussed the reasons that the
patch/feature/&c isn't being accepted.

>> Now the whole n-or-b thing gets into obvious not helpful dialogue 
>> which is not helpful.  I'm sure anyone would agree that if Tom called 
>> me a nigger, it's not helpful to our communication, and you should 
>> therefore tell him to shut-up regardless who he is.
> 
>> So then why call him more valued? It doesn't matter in this context. 
>> Why even bring it up. On technical matters, someone closer to the
>> issue is often a better arbiter of the evidence, but in matters of   
>> interpersonal interactions, no one should be held above another  
>> person.  
>   
> Tom was just an example.  Yes someone closer to the problem would be  
> better and Tom of course would delegate.  My point is people in our   
> community  are more important to us than strangers.  Let's say you
> have 1000 people come and attack you off the street(this is how those 
> SJW's work BTW and why they are so big on that line "It's your
> responsibility to oust your project maintainers").  If you consider   
> their opinions equal to those who have put sweat into the project,
> they will crush you.  A Coc is not only to make new-comers feel   
> welcome, but to protect our long-estabilished project members from
> marauders. 

I don't think I understand your point. So I get 100 friends to come here
and ask for Tom to be outed, we ask for the reason and when they don't
produce a valid one, nothing happens because none of us have any power.
When it comes to committing and governance, there _is_ a hierarchy, and
power is concentrated with a small group. The CoC isn't a place to
discuss how our development structure works. That small group of people
has no more rights against being attacked than anyone else.

Core Comitters, while extremely important to the project technically,
deserve the same respect we expect everyone to show to everyone else.
The CoC is about that respect, not settling technical disputes.

> While we do consider people's feelings, we weigh that against the Time
> and effort of changing long understood terminology that a large   
> majority of people are used to.  Since it's less costly to change new 
> terms, we are more likely to accept changes to newer terminology than 
> changes to long established industry terminology.

I'm not sure how we're on topic anymore, but "it's costly to change our
signage, we're going to continue to keep up the Nigger- and White- Only
signs above the bathroom. I hope you understand." isn't a good argument.

Moreover, I just don't believe they're actually good terms as they're
not really descriptive unless you already know what they mean, but
that's off topic.

Jim


-- 
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] WIP: CoC

[James Keener]

>> That has nothing to do with the Code of Conduct, though.  The 
>> community accepting Tom saying "no" to Feature X is vastly
>> different than the community not calling Tom out for being mean.
> 
>> The CoC is about the later situation and not the prior; and the
>> community should call Tom out. (I'm sure you're a great person,
>> Tom, sorry you're the example being used here.)
> 
> No.  The Coc is about protecting Tom from abuse.  I'm not worried
> about  YOUR good intentions, I'm worried about their bad intentions

Giving Tom special status is not the way to protect Tom from abuse.
We protect Tom from abuse by applying the exact same anti-abuse and
harassment rules that we have for everyone else to Tom. Making
exceptions is never a good thing to do. Tom is covered by the general
case, he does not need an exception. (Sorry Tom. <3)

Jim



-- 
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] WIP: CoC

[James Keener]

>> We value the opinions of members who have contributed most more than
> we value the opinions of others.
> 
>> A CoC is not the place to say some animals are more equal than others. A
> core commiter calling someone the n- or b- words is just as bad as me, a
> non commiter (if not worse!)
> 
> Yes it is.  If a stranger comes and wants something changed, and Tom
> Lane says no. You should go with Tom Lane.  Period.

That has nothing to do with the Code of Conduct, though.  The community
accepting Tom saying "no" to Feature X is vastly different than the
community not calling Tom out for being mean.  The CoC is about the
later situation and not the prior; and the community should call Tom
out. (I'm sure you're a great person, Tom, sorry you're the example
being used here.)

> Now the whole n-or-b thing gets into obvious not helpful dialogue which
> is not helpful.  I'm sure anyone would agree that if Tom called me a
> nigger, it's not helpful to our communication, and you should therefore
> tell him to shut-up regardless who he is.

So then why call him more valued? It doesn't matter in this context. Why
even bring it up. On technical matters, someone closer to the issue is
often a better arbiter of the evidence, but in matters of interpersonal
interactions, no one should be held above another person.

>> While we do consider people's feelings, we weigh that against the
> effort of changing long understood terminology and the psychological trauma
> such changes would cause for the large majority of people who are not as
> sensitive to the usage.
> 
>> What psychological trauma? From changing terms? Are you crazy? (See for
> that you'd like to the CoC to tell me why that wasn't an appropriate way
> to express my disbelief that someone would equate a change of term to
> psychological trauma.
> 
> Think about if all your life when you've been talking about replication
> you've been using master/slave, and someone says from now on, It's
> leader/follower.
> 
> So now in every conference you go to you need to catch yourself when you
> are saying Master/Slave – oops I meant to say Leader / Follower.
> 
> To me that's psychological trauma.  It's the same psychological trauma I
> had to face being born a left-handed and being forced to write with my
> right-hand.

But it's still not trauma, where is the trauma? Something like
Master/Slave to Primary/Replica (which IMHO is a more descriptive term
anyway) would be a long-term, gradual change. In all honesty no one will
care when you slip up because they'll understand it's a change in
progress. I just don't see the trauma.

Jim


-- 
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] WIP: CoC

[James Keener]

Why must it be free of personal comments?

"Tom, I like the way you handed this issue. Good work!" Is a personal comment.

Why do we need lists? What specifically is wrong with "that focuses on the tech 
and not the person" version?

Jim

On January 11, 2016 6:04:03 PM EST, "Joshua D. Drake"  
wrote:
>On 01/11/2016 02:54 PM, Tom Lane wrote:
>> "Joshua D. Drake"  writes:
>>> How about we meet in the middle:
>>
>>> A safe, respectful, productive and collaborative environment is free
>>> of non-technical or personal comments related to gender, sexual
>>> orientation, disability, physical appearance, body size, race or
>>> personal attacks.
>>
>> That's not really meeting in the middle: it still specifies exactly
>> one set of disapproved topics.  Might be OK if it read like
>> "... personal comments, for example ones related to gender, ..."
>
>Tom,
>
>Oh good point. I like that. So:
>
>A safe, respectful, productive and collaborative environment is free
>of non-technical or personal comments, for example ones related to 
>gender, sexual orientation, disability, physical appearance, body size,
>
>race or personal attacks.
>
>Sincerely,
>
>JD
>
>
>-- 
>Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
>PostgreSQL Centered full stack support, consulting and development.
>Announcing "I'm offended" is basically telling the world you can't
>control your own emotions, so everyone else should do it for you.
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

[James Keener]

> We value the opinions of members who have contributed most more than we value 
> the opinions of others.

A CoC is not the place to say some animals are more equal than others. A core 
commiter calling someone the n- or b- words is just as bad as me, a non 
commiter (if not worse!)

> While we do consider people's feelings, we weigh that against the effort of 
> changing long understood terminology and the psychological trauma 
such changes would cause for the large majority of people who are not as 
sensitive to the usage. 

What psychological trauma? From changing terms? Are you crazy? (See for that 
you'd like to the CoC to tell me why that wasn't an appropriate way to express 
my disbelief that someone would equate a change of term to psychological trauma.

Also, "because it's been that way always" and "it would be a minor inconvience 
to a lot of people" are rarely good reasons to dismiss a valid objection to a 
term.

Also, it all sounds too fluffy.

Also, why did you have a quote at the top? Were you responding to something?

Jim

On January 11, 2016 5:56:08 PM EST, Regina Obe  wrote:
>
>> 2. The CoC is not about being offended. The act of being offended is
>purely a recipient response and usually the offended individual is more
>interested in being a victim than moving forward.
>
>Here is my latest version.  Let me know if I should throw in a github
>repo so it's easier to read or if you have other plans for a Coc.
>
>-
>
>
>Like the open source technical community as a whole, our community is
>made up of a mixture of professionals and volunteers with vast
>differences of opinions and 
>styles of communication. Our community is made up of people from many
>cultures and walks of life who have come together 
>with the common goals of making a great piece of software and helping
>others use this software.
>
>We value contributions from everybody. By contributions we mean code,
>documentation, project outreach in form of setting up conferences or
>working groups, 
>package maintenance, answering and asking questions in our forums which
>further our mission, and providing bug reports.
>
>If you have contributed to our project, then we consider you a member
>of our extended family and value your opinions and concerns very
>highly.  
>
>We value the opinions of members who have contributed most more than we
>value the opinions of others.  
>This is because major contributors have already proved their desire to
>further our mission, and for newcomers, 
>their intention has not yet been established.
>
>We want everyone entering our community willing to help out to feel
>welcomed.
>
>To maintain and encourage a welcoming environment we ask all people
>interacting with our community to follow these guidelines when in our
>public spaces.  By public spaces we mean mailing lists, IRC channels,
>Code repositories, and reporting bug reports
>
>GUIDELINES
>
>1) When in discussions keep focused on the topic being discussed. 
>2) Say helpful things, and if you feel you have nothing to say that
>furthers the discussion, say nothing.
>
>By helpful we mean for example:
>If someone asks a question, even if it's one that you think has an
>obvious answer, either provide an example or a link to the section of
>the manual that covers it.
>
>If you feel a person does not provide enough information for someone to
>help, point them to this link:
>https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
>3) Do not switch the topic to yourself unless the topic happens to be
>about you.
>For example if someone is asking a question about replication, and the
>words master and slave come up in discussion,
>do not talk about the great master/slave sex you had last night.
>
>4) Do not ask questions that are unrelated to the mission of our
>project.
>
>USE OF TRIGGER TERMS
>
>We have long standing terms like Master/Slave that may trigger some
>past trauma for some people.
>While we do consider people's feelings, we weigh that against the
>effort of changing long understood terminology and the psychological
>trauma 
>such changes would cause for the large majority of people who are not
>as sensitive to the usage. 
>As such we entertain change requests for naming of new features more
>than we do of renaming old features.
>
>HANDLING ISSUES
>
>We understand that through no fault of anybody, a person may make a
>comment they consider harmless that others find very offensive or makes
>another feel small. As project maintainers
>we will monitor these and gently call people out on them even if they
>are a member of our maintainer group.
>
>By gentle call out, we mean something like "I think what X was trying
>to say was that you need to do this" or point them to this document and
>specific bullet point we feel they violated.
>
>We expect of every

Re: [GENERAL] WIP: CoC

[James Keener]

> A safe, respectful, productive and collaborative environment is one
that focuses on the technical merit of ideas and solutions rather than
on the person behind them.

I still prefer this wording as there is no need for us to list the ways in 
which someone can personally be attacked. Should the list include relative's 
weight, religion, aliveness, past follies, jobs &c. 

The quote above is sufficiently powerful to allow members of this group to 
reprimand anyone for stepping out of bounds without having to shoehorn their 
objection into a very narrow list.

Lists of specific points like this are almost always the wrong way to do 
something general. Title VI (and policies based on it) includes a list for very 
specific reasons and we're seeing the issues that brings as that list isn't 
always inclusive enough.

Jim

On January 11, 2016 5:48:38 PM EST, "Joshua D. Drake"  
wrote:
>On 01/11/2016 02:41 PM, Brian Dunavant wrote:
 "3)  A safe, respectful, productive and collaborative environment
>is
 free of negative personal criticism directed at a member of a
 community, rather than at the technical merit of a topic."

>>
>>> A safe, respectful, productive and collaborative environment is free
>>> of non-technical or personal comments related to gender, sexual
>orientation,
>>> disability, physical appearance, body size or race.
>>
>> Between these two I still prefer my wording here because it
>> encompasses all personal attacks regardless of topic or type and
>> avoids hot-button words that distract from the point and can be used
>> for lawyering.  It also emphasizes the desired behavior instead, that
>> criticism should be about the technical merit of the topic.  "Don't
>be
>> a jerk, and stick to the code."  Maybe even rewording it to be a
>> positive instead of a negative would improve it further.
>>
>> "A safe, respectful, productive and collaborative environment is one
>> that focuses on the technical merit of ideas and solutions rather
>than
>> on the person behind them."
>>
>
>How about we meet in the middle:
>
>A safe, respectful, productive and collaborative environment is free
>of non-technical or personal comments related to gender, sexual 
>orientation, disability, physical appearance, body size, race or 
>personal attacks.
>
>
>
>-- 
>Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
>PostgreSQL Centered full stack support, consulting and development.
>Announcing "I'm offended" is basically telling the world you can't
>control your own emotions, so everyone else should do it for you.
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

[James Keener]

> So is life. We aren't here to wipe butts and change a diaper.

But the original isn't constructive of what to do. If I am attacked personally 
I will feel offended, the point is what I do about it. Whining about bring 
offended vs bringing it up and saying that it is not acceptable behaviour are 
very different.

Worse, the original is nothing more than victim blaming.

Even worse, it's useless as not feeling offence isn't what this is about. What 
to do when you feel offended is.


> A safe, respectful, productive and collaborative environment is free
of non-technical or personal comments related to gender, sexual 
orientation, disability, physical appearance, body size or race
I prefer my or the siblings more positive wording than an explicit negative of 
the types of personal attacks we don't like. We don't want any personal attacks!

Jim

On January 11, 2016 5:44:56 PM EST, "Joshua D. Drake"  
wrote:
>On 01/11/2016 02:30 PM, James Keener wrote:
>> (Sorry for the dup post. I felt having a clean thread without having
>to
>> cross-reference was worth the minor faux pas.)
>>
>>>3. A safe, respectful, productive and collaborative environment is
>free
>> of comments related to gender, sexual orientation, disability,
>physical
>> appearance, body size or race.
>>
>> why not
>>
>>> 3.A safe, respectful, productive and collaborative environment is
>free
>> of ad hominem.
>
>I still think we need the examples which is why I sent this a few 
>minutes ago:
>
>""" A safe, respectful, productive and collaborative environment is
>free
>of non-technical or personal comments related to gender, sexual 
>orientation, disability, physical appearance, body size or race. """
>
>
>> Moreover,
>>
>>>2. The CoC is not about being offended.The act of being offended is
>> purely a recipient response and usually the offended individual is
>more
>> interested in being a victim than moving forward.
>>
>> is very harsh.
>
>So is life. We aren't here to wipe butts and change a diaper. However, 
>yes I do agree that it is harsh. The point is really in relation to #6,
>
>the CoC is not about Social Justice.
>
>There are people in this community, people I know personally who will 
>abuse this CoC if it is not exceedingly clear that their ability to be 
>offended is not relevant.
>
>Sincerely,
>
>JD
>
>
>
>-- 
>Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
>PostgreSQL Centered full stack support, consulting and development.
>Announcing "I'm offended" is basically telling the world you can't
>control your own emotions, so everyone else should do it for you.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

[James Keener]

(Sorry for the dup post. I felt having a clean thread without having to
cross-reference was worth the minor faux pas.)

> 3. A safe, respectful, productive and collaborative environment is free
of comments related to gender, sexual orientation, disability,
physical appearance,
body size or race.

why not

> 3. A safe, respectful, productive and collaborative environment is free
of ad hominem.

I don't see why we need to limit comments like in the original: that's not
the point! The point is that people shouldn't be attacked!

Moreover,

> 2. The CoC is not about being offended. The act of being offended is
purely a recipient response and usually the offended individual is more
interested in being a victim than moving forward.

is very harsh.  It definitely needs to be rephrased or built on. What is
the point of this, by the way? If we state that personal attacks are
unbecoming of a member of this group, then does it matter if I'm offended
when someone says we should have a table that lacks 1-M 1-F constraints for
marriage? It's not an attack and trying to clarify the differences between
being offended because of an attack on me or just in general might make
things too awkward to write.

Jim

On Mon, Jan 11, 2016 at 5:27 PM, Joshua D. Drake 
wrote:

> On 01/11/2016 02:22 PM, Brian Dunavant wrote:
>
>> 3. A safe, respectful, productive and collaborative environment is free
>>> comments related to gender, sexual orientation, disability, physical
>>> appearance, body size or race.
>>>
>>
>> I think you meant "free OF comments".
>>
>
> I did.
>
>
>> However it still picks a few special classes of complaint, some of
>> which cause ambiguity such as 'gender'.  Does that mean I can't use
>> "he/she" pronouns?  It also implies that i'm allowed to criticize
>> people in other ways, say, their political affiliation or country.
>> Rather than list a bunch of "no no" perhaps something like:
>>
>> "3)  A safe, respectful, productive and collaborative environment is
>> free of negative personal criticism directed at a member of a
>> community, rather than at the technical merit of a topic."
>>
>>
> First, I want to make sure we don't get too far into the weeds here.
>
> I think your example is a good one but I do think we need examples so
> perhaps:
>
> A safe, respectful, productive and collaborative environment is free
> of non-technical or personal comments related to gender, sexual
> orientation, disability, physical appearance, body size or race.
>
> ???
>
> Sincerely,
>
> JD
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>
>
> --
> 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] Code of Conduct: Is it time? (WIP CoC)

[James Keener]

> 3. A safe, respectful, productive and collaborative environment is free
of comments related to gender, sexual orientation, disability,
physical appearance,
body size or race.

why not

> 3. A safe, respectful, productive and collaborative environment is free
of ad hominem. (Tip: Ask your self "Would I make this same comment if my
best friend or parent stated what I was replying to" if you're unsure.)

The tip being optional, of course :-p  I don't see why we need to limit
comments like in the original: that's not the point! The point is that
people shouldn't be attacked!


Moreover,

> 2. The CoC is not about being offended. The act of being offended is
purely a recipient response and usually the offended individual is more
interested in being a victim than moving forward.

is very harsh.  It definitely needs to be rephrased or built on. What is
the point of this, by the way? If we state that personal attacks are
unbecoming of a member of this group, then does it matter if I'm offended
when someone says we should have a table that lacks 1-M 1-F constraints for
marriage? It's not an attack and trying to clarify the differences between
being offended because of an attack on me or just in general might make
things too awkward to write.

Jim

On Mon, Jan 11, 2016 at 5:15 PM, FarjadFarid(ChkNet) <
farjad.fa...@checknetworks.com> wrote:

>
> Thanks Joshua for creating this list. Great starting point and hopefully
> points to focus on to conclude this thread.
>
> Here are my humble comments on them.
>
> I think point two is already covered by respecting other people's opinion.
> At times specially over email ,where we don't see others reactions , people
> can unintentionally be more confrontational than normal. Therefore it is
> not just the recipient.
>
> Perhaps Point 3 should read "free from".
>
> Thanks again Joshua.
>
> Best Regards
>
>
> Farjad
>
>
> -Original Message-
> From: Joshua D. Drake [mailto:j...@commandprompt.com]
> Sent: 11 January 2016 22:00
> To: FarjadFarid(ChkNet); 'Kevin Grittner'; 'Regina Obe'
> Cc: 'Tom Lane'; 'Karsten Hilbert'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Code of Conduct: Is it time? (WIP CoC)
>
> Hello,
>
> Below please find a WIP CoC for the PostgreSQL.Org project:
>
> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. The CoC is not about being offended. The act of being offended is
> purely a recipient response and usually the offended individual is more
> interested in being a victim than moving forward.
>
> 3. A safe, respectful, productive and collaborative environment is free
> comments related to gender, sexual orientation, disability, physical
> appearance, body size or race.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.
>
> 6. The CoC is not about Social Justice.
>
>
> Sincerely,
>
> JD
>
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't control
> your own emotions, so everyone else should do it for you.
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

[GENERAL] Bug Tracker

[James Keener]

There was a side thread in the CoC thread about expanding the dev community
and making it easier for new devs to get involved. I would think that a bug
tracker, especially one where bugs can be labeled as "Newbie Friendly"
could go a long way towards that goal.

Additionally, a proper bug tracker would make it easier for future users to
find resolutions to issues.

Are there any technical reasons that the project doesn't use a bug tracker
(beyond pgsql-bugs)?

Jim

Re: [GENERAL] Charging for PostgreSQL

[James Keener]

How does one "start a new thread"? I wasn't aware that changing the subject 
wouldn't be enough. I tried :/

Jim

On January 6, 2016 12:17:54 PM EST, "Stéphane Schildknecht" 
 wrote:
>On 06/01/2016 16:54, James Keener wrote:
>> As Melvin mentioned, this belongs in a new thread.
>
>And as such, it would have been really kind to actually start a new
>one.
>
>(...)
>-- 
>Stéphane Schildknecht
>Contact régional PostgreSQL pour l'Europe francophone
>Loxodata - Conseil, expertise et formations
>06.17.11.37.42
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] Code of Conduct: Is it time?

[James Keener]

> No, CoC by itself doesn't grow the community. That doesn't mean we
> shouldn't have one.
I'd agree with that. Thinking back over my previous points, it does make
sense to have one, if only to deal with people who represent the
community in some way, i.e. have some kind of commit or marketing access.

> Another weakness we have is the mentality that the only way to
> contribute to the community is as a developer.
Perhaps this is a separate issue from having a CoC.

Things like not having a bug tracker [1] prevent people from finding
issues to even be involved with, including the website, marketing, code,
tests, &c. That was 10 years ago and it's still the first result for
"Postgres bug tracker" on Google.


-- 
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] Code of Conduct: Is it time?

[James Keener]

> The coc sounds like a Washington politics play, but as long as the best
> still engage
> in this forum, I could care less. The list serves its purpose without
> overhead...a rare
> resource in today's flood of incoherent technical chatter.

Beyond "Hey! Look at us! We're telling people to play nice" What would a
Code of Conduct actually get the community? Is not having a formal "play
nice" document actually keeping developers away?

However, what happens if I break the CoC? Email addresses and IRC
handles are cheap. I can still continue to use PostgreSQL. If I say an
incredibly racist, sexist, or just plain rude thing, then what do I
loose? What do we do when someone harasses someone else in private?

That said, I would capitulate that a document stating the behavior we
expect of each other as a useful way in helping us tell people to stand
down. However, we have to accept that in-and-off itself it's a
meaningless document. Like the US Constitution, it only matters if
people execute and make it matter. (I guess the same idea applies
elsewhere, but hey, I'm a Pennsylvania.) However, unlike a government,
there is no force that we can use against each other.

_We_ as a community need to take the responsibility of telling each
other off when someone steps out of line. If a (short) document
explaining the goals, values, and precepts of the community will help us
do that, then by all means, let's do that!

We just have to figure out if it will. (As a cis-hetero white middle
class male) I'm not a "targeted" group and as such my views may not be
of the most use here.

Jim


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

[GENERAL] Charging for PostgreSQL

[James Keener]

As Melvin mentioned, this belongs in a new thread.

> Just one last example. Consider the music industry. For years Apple amongst 
> others promoted low cost per unit downloads and then streaming. We all know 
> the history. 
> 
> Once a thriving industry music industry has been decimated. Neither the 
> musicians nor song writers receive proper income any more.  
> All the major players recognise its current state is unsustainable. 
So? In an odd twist of things, the developers here are either being paid
to work on PostgreSQL or are _volunteering_ their time. It would be
extremely rude to take their _volunteered_ time and profit from it.
Ditto for support, such as this forum and the IRC channel.

We can debate the music industry all day. My view is that it's
inefficient, corrupt, and poorly managed. A more streamlined system
would result in more money to the artists themselves. They are not a
good comparison to a F/OSS project.

> *I am sure neither of us want to see postgresql to falter.*
And I have no idea how you think charging for PostgreSQL won't make it
falter. People will move to other free databases or move to paid
offerings along the thought process of "no one was ever fired for buying
ibm"

> Of course the right balance needs to be struck but for me at least the idea 
> of free lunch has had its day. 
How does PostgreSQL being free affect you in a _negative_ way? This
"free lunch" is the reason we have the technology and world that we do.
I'm honestly curious why you have an issue with this. Not charging for
code has not prevented a plethora of other projects from having a
growing community. Those issues become moot when you force the community
to disappear. We need to understand what keeps new devs away and fix it
-- not simply force everyone away.

> There can be a low enough charge that people don't feel too much of a pinch 
> but enough to sustain the progress of postgresql.
No. There can't. Going from free to anything will decrease your user
base, especially when there are free alternatives and very large, and
(unfortunately) trusted names you can pay for a database. I've dealt
with this at many companies.

> I genuinely don't like arguments over emails. These are complex issues.
I personally find it easier than arguing in person. But to each his own.
If you don't like arguing then there is nothing that says you must argue.

> Again I for one will continue to support postgresql team whatever their 
> decision may be. 
That decision has already been made. Unless you can overcome the
_idealogical_
reason that PostgreSQL is F/OSS in the first place, then I'm not sure
this is an argument worth continuing.

Jim

> 
> 
> 
> -Original Message-
> From: pgsql-general-ow...@postgresql.org 
> [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of James Keener
> Sent: 06 January 2016 15:04
> To: FarjadFarid(ChkNet); 'Karsten Hilbert'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Code of Conduct: Is it time?
> 
>> My only aim is further progress of postgresql.
> Charging for it would do exactly that. Most people would simply switch to 
> MySQL (or Maria) or stop upgrading/upgrade to a fork.
> 
>> As per Sun Microsystem’s case charging zero dollars (for Java and 
>> mysql)  means there is zero income.
> Why do you think this is a company? There _are_ companies that offer support 
> and coding. While I'm sure everyone would agree that developers should be 
> able to eat (and more/better than Raman), the point of the "The PostgreSQL 
> Global Development Group" and being "The world's most advanced open source 
> database" is not to become Ellison. The commercial support and consulting 
> offerings are there to make the money. The rest of us plebs just have to help 
> each other out.
> 
> Had PostgreSQL started out/never became open source, we would be having a 
> very different discussion (about a very different product, if it still 
> existed). As it stands, fundamentally shifting the goals, objectives, MO of a 
> libre and beer free software project to something other than that is going to 
> be met with a lot of resistance because it shifts how we as users interact 
> with something we've interacted with in a certain way and with certain 
> expectations for years.
> 
>> Emails are not the best medium for consulting about complex issues.
> Emails are actually a decent medium because they allow one to express 
> themselves in a well thought out and clear way. It just has to be used 
> correctly (and I'm not insinuating I'm great at that).
> 
> I'm not sure who Farjad is; is this a serious proposal or "just something 
> someone said"? I feel religious about PostgreSQL as it rea

Re: [GENERAL] Code of Conduct: Is it time?

[James Keener]

> My only aim is further progress of postgresql.
Charging for it would do exactly that. Most people would simply switch
to MySQL (or Maria) or stop upgrading/upgrade to a fork.

> As per Sun Microsystem’s case charging zero dollars (for Java and mysql)
>  means there is zero income.
Why do you think this is a company? There _are_ companies that offer
support and coding. While I'm sure everyone would agree that developers
should be able to eat (and more/better than Raman), the point of the
"The PostgreSQL Global Development Group" and being "The world's most
advanced open source database" is not to become Ellison. The commercial
support and consulting offerings are there to make the money. The rest
of us plebs just have to help each other out.

Had PostgreSQL started out/never became open source, we would be having
a very different discussion (about a very different product, if it still
existed). As it stands, fundamentally shifting the goals, objectives, MO
of a libre and beer free software project to something other than that
is going to be met with a lot of resistance because it shifts how we as
users interact with something we've interacted with in a certain way and
with certain expectations for years.

> Emails are not the best medium for consulting about complex issues.
Emails are actually a decent medium because they allow one to express
themselves in a well thought out and clear way. It just has to be used
correctly (and I'm not insinuating I'm great at that).

I'm not sure who Farjad is; is this a serious proposal or "just
something someone said"? I feel religious about PostgreSQL as it really
has changed how I view databases in general (and you know what they say
about converts). Not that I matter, but I would feel a huge blow if I
could no longer tell people to use it.

Jim


-- 
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] Code of Conduct: Is it time?

[James Keener]

What are you talking about? What business structure? Commercial offerings can 
and will continue to exist in terms of custom features or consulting.

Firstly, it ceases to be a community version when there is a charge. Secondly, 
it would damage our community by shrinking the size to effectively none while a 
hard fork (or more) spring up and people migrate to them. Moreover, unless you 
change the license people will redistribute newer versions for free.

So, while I have no say so in any of this, I believe it would be a very short 
sighted move. There are many other ways that money for the oss/foundation can 
be raised if money or supplies are needed.

Jim

On January 6, 2016 9:14:21 AM EST, "FarjadFarid(ChkNet)" 
 wrote:
>Hi Karsten,
>
>> You may be mistaking the community version for any of the
>commercially
>supported offerings ?
>
>It is possible. Please fill in the figures. 
>
>What I am suggesting is that even for community version there should be
>a
>charge. 
>
>But as I mentioned it is not just prices. 
>
>May be I wasn't very clear the most important factor is the business
>structure then quality of products and marketing together with pricing.
>  
>
>As a further example consider how a very small company like ARM beat
>giants
>like Intel and Samsung in the mobile phone industry.  
>
>It is their business model that is not profitable for Intel and Samsung
>to
>emulate. 
>
>*Of course they have a great products. Equally importantly their
>business
>model makes it realistic and profitable for other 
>companies to use their services.  *
>
>I am only providing some food for thought. For me we can all learn from
>other people's successes and failures. 
>
>I for one think everyone on the team have done a great job bringing
>postgresql to this stage. 
>
>Good luck
>
>
>
>Farjad Farid
>
>
>
>
>-Original Message-
>From: pgsql-general-ow...@postgresql.org
>[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Karsten
>Hilbert
>Sent: 06 January 2016 11:32
>To: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] Code of Conduct: Is it time?
>
>On Wed, Jan 06, 2016 at 11:22:17AM -, FarjadFarid(ChkNet) wrote:
>
>> I am not in favour of massive price structures but that there should 
>> be $100-$200 costs for smallest version. Times several million 
>> products. This may allow postgresql to reduce its prices on its the 
>> top of the range products.
>
>You may be mistaking the community version for any of the commercially
>supported offerings ?
>
>Regards,
>Karsten
>--
>GPG key ID E4071346 @ eu.pool.sks-keyservers.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general
>
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL]

[James Keener]

Who were you logged I to psql as? Does the dump switch users?

On November 13, 2015 12:38:19 AM EST, Alex Luya  
wrote:
>Hello,
>   I created a new database by
>
>   create database icare;
>
>   then quit off psql and  run:
>
>pg_restore --clean --create --exit-on-error --dbname=icare
>icare-test.tar
>
> it complains:
>
>  pg_restore: [archiver (db)] Error while PROCESSING TOC:
>pg_restore: [archiver (db)] Error from TOC entry 21; 2615 80924
>SCHEMA icare icare
>  pg_restore: [archiver (db)] could not execute query: ERROR:
> permission denied for database icare
>   Command was: CREATE SCHEMA icare;

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] Multiple insert

[James Keener]

You are inserting ((),()). It should be (),(). Skip the outer set of 
parentheses.

On September 19, 2015 2:31:53 PM EDT, "FarjadFarid(ChkNet)" 
 wrote:
>Hi, 
>
> 
>
>I am getting errors trying to insert multiple records in single
>statement in
>table like this
>
> 
>
>CREATE TABLE "Lookup"."CNEnum1"
>
>(
>
>  "Id" integer NOT NULL,
>
>  "Description" character varying(50),
>
>  CONSTRAINT "PK_Lookup_CNEnum1 " PRIMARY KEY ("Id")
>
>)
>
>WITH (
>
>  OIDS=FALSE
>
>);
>
> 
>
>INSERT INTO "Lookup"." CNEnum1"(" Id
>","Description")VALUES((1::integer,'Desc1'::varchar)
>,(2::ineger,''Desc2'::varchar))
>
> 
>
>I have tried various versions of sql statement. With field casting and
>without casting.  Both work when a single record is inserted but with
>multiple records the same error is reported. 
>
> 
>
>ERROR:  column "Id" is of type integer but expression is of type record
>
>LINE 1: ... CNEnum1"("Id","Description")VALUES((1::int,'D...
>
> ^
>
>HINT:  You will need to rewrite or cast the expression.
>
>** Error **
>
> 
>
>ERROR: column "Id" is of type integer but expression is of type record
>
>SQL state: 42804
>
>Hint: You will need to rewrite or cast the expression.
>
>Character: 73
>
> 
>
>Any suggestion would be greatly welcomed! And thank you in advance. 
>
> 
>
>Kind Regards
>
> 
>
> 
>
>Farjad
>
> 
>
> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] Anyone interested in a Pittsburgh-area Postgres users'

[James Keener]

Is there a user group in Pittsburgh?  This email was the first that
showed up in a Google Search.

Jim

On 2004-05-02 05:43:26, Tom Lane wrote:

> I've gotten a couple of inquiries lately about a Postgres users' group
> in my home town of Pittsburgh PA.  There is not one (unless it's very
> well camouflaged) but perhaps there is critical mass to create one.
> If you think you might come to meetings of such a group, let me know
> off-list.  If I get enough responses I'll set up an initial meeting
> and we'll see where it goes ...
> 
>   regards, tom lane





signature.asc
Description: OpenPGP digital signature