agora inbox for [email protected]
help / color / mirror / Atom feedCode of Conduct
35+ messages / 20 participants
[nested] [flat]
* Code of Conduct
@ 2018-09-18 10:27 Dave Page <[email protected]>
0 siblings, 3 replies; 35+ messages in thread
From: Dave Page @ 2018-09-18 10:27 UTC (permalink / raw)
To: [email protected]; pgsql-generallists.postgresql.org <[email protected]>
The PostgreSQL Core team are pleased to announce that following a long
consultation process, the project’s Code of Conduct (CoC) has now been
finalised and published at https://www.postgresql.org/about/policies/coc/.
Please take time to read and understand the CoC, which is intended to
ensure that PostgreSQL remains an open and enjoyable project for anyone to
join and participate in.
A Code of Conduct Committee has been formed to handle any complaints. This
consists of the following volunteers:
- Stacey Haysler (Chair)
- Lætitia Avrot
- Vik Fearing
- Jonathan Katz
- Ilya Kosmodemiansky
We would like to extend our thanks and gratitude to Stacey Haysler for her
patience and expertise in helping develop the Code of Conduct, forming the
committee and guiding the work to completion.
--
Dave Page
PostgreSQL Core Team
http://www.postgresql.org/
<http://www.postgresql.org/;
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 11:47 James Keener <[email protected]>
parent: Dave Page <[email protected]>
2 siblings, 2 replies; 35+ messages in thread
From: James Keener @ 2018-09-18 11:47 UTC (permalink / raw)
To: [email protected]; Dave Page <[email protected]>; [email protected]; pgsql-generallists.postgresql.org <[email protected]>
> following a long consultation process
It's not a consultation if any dissenting voice is simply ignored. Don't sugar-coat or politicize it like this -- it was rammed down everyone's throats. That is core's right, but don't act as everyone's opinions and concerns were taken into consideration. There are a good number of folks who are concerned that this CoC is overreaching and is ripe for abuse. Those concerns were always simply, plainly, and purposely ignored.
> Please take time to read and understand the CoC, which is intended to ensure that PostgreSQL remains an open and enjoyable project for anyone to join and participate in.
I sincerely hope so, and that it doesn't become a tool to enforce social ideology like in other groups I've been part of. Especially since this is the main place to come to get help for PostgreSQL and not a social club.
Jim
On September 18, 2018 6:27:56 AM EDT, Dave Page <[email protected]> wrote:
>The PostgreSQL Core team are pleased to announce that following a long
>consultation process, the project’s Code of Conduct (CoC) has now been
>finalised and published at
>https://www.postgresql.org/about/policies/coc/.
>
>Please take time to read and understand the CoC, which is intended to
>ensure that PostgreSQL remains an open and enjoyable project for anyone
>to
>join and participate in.
>
>A Code of Conduct Committee has been formed to handle any complaints.
>This
>consists of the following volunteers:
>
>- Stacey Haysler (Chair)
>- Lætitia Avrot
>- Vik Fearing
>- Jonathan Katz
>- Ilya Kosmodemiansky
>
>We would like to extend our thanks and gratitude to Stacey Haysler for
>her
>patience and expertise in helping develop the Code of Conduct, forming
>the
>committee and guiding the work to completion.
>
>--
>Dave Page
>PostgreSQL Core Team
>http://www.postgresql.org/
><http://www.postgresql.org/;
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 14:34 Tomas Vondra <[email protected]>
parent: James Keener <[email protected]>
1 sibling, 2 replies; 35+ messages in thread
From: Tomas Vondra @ 2018-09-18 14:34 UTC (permalink / raw)
To: James Keener <[email protected]>; [email protected]; Dave Page <[email protected]>; [email protected]
On 09/18/2018 01:47 PM, James Keener wrote:
> > following a long consultation process
>
> It's not a consultation if any dissenting voice is simply ignored.
> Don't sugar-coat or politicize it like this -- it was rammed down
> everyone's throats. That is core's right, but don't act as everyone's
> opinions and concerns were taken into consideration.
I respectfully disagree.
I'm not sure which dissenting voices you think were ignored, but from
what I've observed in the various CoC threads the core team took the
time to respond to all comments. That does not necessarily mean the
resulting CoC makes everyone happy, but unfortunately that's not quite
possible. And it does not mean it was not an honest consultation.
IMO the core team did a good job in listening to comments, tweaking the
wording and/or explaining the reasoning. Kudos to them.
> There are a good number of folks who are concerned that this CoC is
> overreaching and is ripe for abuse. Those concerns were always
> simply, plainly, and purposely ignored.
No, they were not. There were multiple long discussions about exactly
these dangers, You may dislike the outcome, but it was not ignored.
> > Please take time to read and understand the CoC, which is intended to
> ensure that PostgreSQL remains an open and enjoyable project for anyone
> to join and participate in.
>
> I sincerely hope so, and that it doesn't become a tool to enforce social
> ideology like in other groups I've been part of. Especially since this
> is the main place to come to get help for PostgreSQL and not a social club.
>
Ultimately, it's a matter of trust that the CoC committee and core team
apply the CoC in a careful and cautious way. Based on my personal
experience with most of the people involved in both groups I'm not
worried about this part.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 16:27 James Keener <[email protected]>
parent: Tomas Vondra <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: James Keener @ 2018-09-18 16:27 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]>; Dave Page <[email protected]>; [email protected]
>
> You may dislike the outcome, but it was not ignored.
I can accept that I don't like the outcome, but I can point to maybe a
dozen people in the last
exchange worried about the CoC being used to further political goals, and
the only response
was "well, the CoC Committee will handle it reasonable" which is not a good
answer, because
that's exactly the situation that we are worried about not happening! These
concerns were never
actually addressed and always just brushed aside -- that's what I found
bothersome and worrisome.
We shouldn't have to expect the rules to be applied fairly in order to
counter actual abuses of the
rules. I've seen it in other groups and have been the target of such
actions. (I had the gall to claim
that hiring practices that require submitting side- or open-source- work
aren't only detrimental to
women because they statistically shoulder more of the housework and
childcare, but also to
husbands and fathers who take an active role in the household and
childcare. It wasn't intended to
diminish the effect this hiring practice has on women, but to suggest that
it's a broader problem than
the conversation at that point was making it out to be. I was subsequently
silenced and eventually
booted from the group for that incident and another, in a social channel,
where a discussion on guns
was taking place and someone said that the discussion is sexist and this is
why there are so few
female programmers, and I had the impertinence to say that I know more
women who hunt and shot
for sport then men (it's ~50-50 in this area). Forgive me for not having a
favourable view of CoCs.)
So, it's not that I don't trust the CoC Committee, but I just really don't
trust most people. The clearer
the rules the better. As it stands, the rules are extremely vague and
overreaching.
Jim
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 17:08 Chris Travers <[email protected]>
parent: Tomas Vondra <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Chris Travers @ 2018-09-18 17:08 UTC (permalink / raw)
To: [email protected]; +Cc: James Keener <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; [email protected]; [email protected]
On Tue, Sep 18, 2018 at 4:35 PM Tomas Vondra <[email protected]>
wrote:
> On 09/18/2018 01:47 PM, James Keener wrote:
> > > following a long consultation process
> >
> > It's not a consultation if any dissenting voice is simply ignored.
> > Don't sugar-coat or politicize it like this -- it was rammed down
> > everyone's throats. That is core's right, but don't act as everyone's
> > opinions and concerns were taken into consideration.
>
> I respectfully disagree.
>
> I'm not sure which dissenting voices you think were ignored, but from
> what I've observed in the various CoC threads the core team took the
> time to respond to all comments. That does not necessarily mean the
> resulting CoC makes everyone happy, but unfortunately that's not quite
> possible. And it does not mean it was not an honest consultation.
>
> IMO the core team did a good job in listening to comments, tweaking the
> wording and/or explaining the reasoning. Kudos to them.
>
I said I would stand aside my objections after the last point I mentioned
them but I did not feel that my particular objection and concern with
regard to one specific sentence added got much of a hearing. This being
said, it is genuinely hard to sort through the noise and try to reach the
signal. I think the resurgence of the debate about whether we need a code
of conduct made it very difficult to discuss specific objections to
specific wording. So to be honest the breakdown was mutual.
>
> > There are a good number of folks who are concerned that this CoC is
> > overreaching and is ripe for abuse. Those concerns were always
> > simply, plainly, and purposely ignored.
> No, they were not. There were multiple long discussions about exactly
> these dangers, You may dislike the outcome, but it was not ignored.
>
Also those of us who had specific, actionable concerns were often drowned
out by the noise. That's deeply unfortunate.
I think those of us who had specific concerns about one specific sentence
that was added were drowned out by those who seemed to be opposed to the
idea of a code of conduct generally.
I would have appreciated at least a reason why the concerns I had about the
fact that the addition a) doesn't cover what it is needs to cover, and b)
will attract complaints that it shouldn't cover was not considered valid.
But I can understand that given the noise-to-signal ratio of the discussion
made such discussion next to impossible.
Again I find that regrettable.
>
> > > Please take time to read and understand the CoC, which is intended to
> > ensure that PostgreSQL remains an open and enjoyable project for anyone
> > to join and participate in.
> >
> > I sincerely hope so, and that it doesn't become a tool to enforce social
> > ideology like in other groups I've been part of. Especially since this
> > is the main place to come to get help for PostgreSQL and not a social
> club.
> >
>
> Ultimately, it's a matter of trust that the CoC committee and core team
> apply the CoC in a careful and cautious way. Based on my personal
> experience with most of the people involved in both groups I'm not
> worried about this part.
>
I would actually go further than you here. The CoC committee *cannot*
apply the CoC in the way that the opponents fear. The fact is, Europe has
anti-discrimination laws regarding social and political ideology (something
the US might want to consider as it would help avoid problems on this list
;-) ). And different continents have different norms on these sorts of
things. Pushing a social ideology via the code of conduct would, I
suspect, result in everything from legal action to large emerging markets
going elsewhere. So I don't think ti is a question of "trust us" but
rather that the community won't let that sort of abuse happen no matter who
is on the CoC committee.
>
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 17:14 Stephen Frost <[email protected]>
parent: Chris Travers <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Stephen Frost @ 2018-09-18 17:14 UTC (permalink / raw)
To: Chris Travers <[email protected]>; +Cc: [email protected]; James Keener <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; [email protected]; [email protected]
Greetings,
* Chris Travers ([email protected]) wrote:
> I said I would stand aside my objections after the last point I mentioned
> them but I did not feel that my particular objection and concern with
> regard to one specific sentence added got much of a hearing. This being
> said, it is genuinely hard to sort through the noise and try to reach the
> signal. I think the resurgence of the debate about whether we need a code
> of conduct made it very difficult to discuss specific objections to
> specific wording. So to be honest the breakdown was mutual.
I would ask that you, and anyone else who has a suggestion for how to
improve or revise the CoC, submit your ideas to the committee by
email'ing [email protected].
As was discussed previously, the current CoC isn't written in stone and
it will be changed and amended as needed.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 18:35 Tom Lane <[email protected]>
parent: Stephen Frost <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Tom Lane @ 2018-09-18 18:35 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Chris Travers <[email protected]>; [email protected]; James Keener <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; [email protected]
Stephen Frost <[email protected]> writes:
> I would ask that you, and anyone else who has a suggestion for how to
> improve or revise the CoC, submit your ideas to the committee by
> email'ing [email protected].
> As was discussed previously, the current CoC isn't written in stone and
> it will be changed and amended as needed.
The change process is spelled out explicitly in the CoC document.
I believe though that the current plan is to wait awhile (circa 1 year)
and get some experience with the current version before considering
changes.
regards, tom lane
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-18 18:40 Chris Travers <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Chris Travers @ 2018-09-18 18:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Stephen Frost <[email protected]>; [email protected]; James Keener <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; [email protected]
On Tue, Sep 18, 2018 at 8:35 PM Tom Lane <[email protected]> wrote:
> Stephen Frost <[email protected]> writes:
> > I would ask that you, and anyone else who has a suggestion for how to
> > improve or revise the CoC, submit your ideas to the committee by
> > email'ing [email protected].
> > As was discussed previously, the current CoC isn't written in stone and
> > it will be changed and amended as needed.
>
> The change process is spelled out explicitly in the CoC document.
>
> I believe though that the current plan is to wait awhile (circa 1 year)
> and get some experience with the current version before considering
> changes.
>
My $0.02:
If you are going to have a comment period, have a comment period and
actually deliberate over changes.
If you are going to just gather feedback and wait a year, use some sort of
issue system.
Otherwise, there is no reason to think that feedback gathered now will have
any impact at all in the next revision.
>
> regards, tom lane
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 01:24 Julian Paul <[email protected]>
parent: Dave Page <[email protected]>
2 siblings, 1 reply; 35+ messages in thread
From: Julian Paul @ 2018-09-19 01:24 UTC (permalink / raw)
To: [email protected]
On 18/09/18 20:27, Dave Page wrote:
> The PostgreSQL Core team are pleased to announce that following a long
> consultation process, the project’s Code of Conduct (CoC) has now been
> finalised and published at https://www.postgresql.org/about/policies/coc/.
>
> Please take time to read and understand theCoC, which is intended to
> ensure that PostgreSQL remains an open and enjoyable project for anyone
> to join and participate in.
>
> A Code of Conduct Committee has been formed to handle any complaints.
> This consists of the following volunteers:
>
> - Stacey Haysler (Chair)
> -LætitiaAvrot
> - Vik Fearing
> - Jonathan Katz
> - Ilya Kosmodemiansky
>
> We would like to extend our thanks and gratitude to Stacey Haysler for
> her patience and expertise in helping develop the Code of Conduct,
> forming the committee and guiding the work to completion.
>
> --
> Dave Page
> PostgreSQL Core Team
> http://www.postgresql.org/
> <http://www.postgresql.org/;
It's overly long and convoluted.
"inclusivity" Is a ideologue buzzword of particular individuals that
offer very little value apart from excessive policing of speech and
behaviour assumed to be a problem where none exist.
"Personal attacks and negative comments on personal characteristics are
unacceptable, and will not be permitted. Examples of personal
characteristics include, but are not limited to age, race, national
origin or ancestry, religion, gender, or sexual orientation."
So just leaving it at "Personal attacks" and ending it there won't do
obviously. I'm a big advocate of people sorting out there own personal
disputes in private but...
"further personal attacks (public or *private*);"
...lets assume people don't have the maturity for that and make it all
public.
"may be considered offensive by fellow members" - Purely subjective and
irrelevant to a piece of community software.
There is much more in this CoC that is concerning and appears to follow
the same methodology to be nothing more than a green light to those who
have made their way within the inner hierarchy to run it like a overly
politicized dictatorship.
I'm not sure if there is likely to be a large concerning number of
people that are likely to violate this CoC. However, it is written in a
such a way that will open it up to heavy handed abuse.
The fact that this CoC made it this far to be actually published is
concerning and IMO alludes to requests for feedback to not be taken
seriously. In fact I'm somewhat certain of this.
I assumed this was a open community with a large number of voluntary
members. Remember this is a piece of software most end users don't know
or even should care about.
K.I.S.S. That's my feedback.
Regards, Julian.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 14:30 ERR ORR <[email protected]>
parent: James Keener <[email protected]>
1 sibling, 2 replies; 35+ messages in thread
From: ERR ORR @ 2018-09-19 14:30 UTC (permalink / raw)
To: James Keener <[email protected]>; +Cc: Dave Page <[email protected]>; [email protected]; pgsql-generallists.postgresql.org <[email protected]>
I was never consulted.
I was only Told that there was a CoC "to be". Not when, not how.
A CoC will inevitably lead to the project taken over by leftists, political
and technical decisions will be made by others.
Most important from my PoV, the projects quality will decrease until its
made unviable.
As others have said, this was rammed down our throats.
Before you ppl become unemployed, read "SJWs always lie". You'll know what
awaits you.
As for myself, I'll be on the lookout for another DB. One that's not
infiltrated by leftist nuts.
And Dave, you can tell the core team a big "FUCK YOU" for this.
James Keener <[email protected]> schrieb am Di., 18. Sep. 2018, 13:48:
> > following a long consultation process
>
> It's not a consultation if any dissenting voice is simply ignored. Don't
> sugar-coat or politicize it like this -- it was rammed down everyone's
> throats. That is core's right, but don't act as everyone's opinions and
> concerns were taken into consideration. There are a good number of folks
> who are concerned that this CoC is overreaching and is ripe for abuse.
> Those concerns were always simply, plainly, and purposely ignored.
>
> > Please take time to read and understand the CoC, which is intended to
> ensure that PostgreSQL remains an open and enjoyable project for anyone to
> join and participate in.
>
> I sincerely hope so, and that it doesn't become a tool to enforce social
> ideology like in other groups I've been part of. Especially since this is
> the main place to come to get help for PostgreSQL and not a social club.
>
> Jim
>
> On September 18, 2018 6:27:56 AM EDT, Dave Page <[email protected]>
> wrote:
>>
>> The PostgreSQL Core team are pleased to announce that following a long
>> consultation process, the project’s Code of Conduct (CoC) has now been
>> finalised and published at https://www.postgresql.org/about/policies/coc/
>> .
>>
>> Please take time to read and understand the CoC, which is intended to
>> ensure that PostgreSQL remains an open and enjoyable project for anyone to
>> join and participate in.
>>
>> A Code of Conduct Committee has been formed to handle any complaints.
>> This consists of the following volunteers:
>>
>> - Stacey Haysler (Chair)
>> - Lætitia Avrot
>> - Vik Fearing
>> - Jonathan Katz
>> - Ilya Kosmodemiansky
>>
>> We would like to extend our thanks and gratitude to Stacey Haysler for
>> her patience and expertise in helping develop the Code of Conduct, forming
>> the committee and guiding the work to completion.
>>
>> --
>> Dave Page
>> PostgreSQL Core Team
>> http://www.postgresql.org/
>> <http://www.postgresql.org/;
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 15:27 Fred Pratt <[email protected]>
parent: ERR ORR <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Fred Pratt @ 2018-09-19 15:27 UTC (permalink / raw)
To: ERR ORR <[email protected]>; +Cc: James Keener <[email protected]>; Dave Page <[email protected]>; [email protected] <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>
Keep pg open and free. This smells of PC police. This community can police itself
Sent from my mobile device. Please pardon my brevity and typos. I am not responsible for changes made by this device’s autocorrect feature.
Fred Pratt
AmerisourceBergen
Manager – IT Infrastructure
Micro Technologies
8701 CenterPort Blvd<x-apple-data-detectors://8>
Amarillo, TX 79108<x-apple-data-detectors://8>
Work: 806.372.2369 (Ext. 8364)<tel:806.372.2369;8364>
Fax: 855.849.0680<tel:855.849.0680>
Mobile: 806.679.1742<tel:806.679.1742>
microtechnologies.com<http://microtechnologies.com/;
On Sep 19, 2018, at 9:32 AM, ERR ORR <[email protected]<mailto:[email protected]>> wrote:
I was never consulted.
I was only Told that there was a CoC "to be". Not when, not how.
A CoC will inevitably lead to the project taken over by leftists, political and technical decisions will be made by others.
Most important from my PoV, the projects quality will decrease until its made unviable.
As others have said, this was rammed down our throats.
Before you ppl become unemployed, read "SJWs always lie". You'll know what awaits you.
As for myself, I'll be on the lookout for another DB. One that's not infiltrated by leftist nuts.
And Dave, you can tell the core team a big "FUCK YOU" for this.
James Keener <[email protected]<mailto:[email protected]>> schrieb am Di., 18. Sep. 2018, 13:48:
> following a long consultation process
It's not a consultation if any dissenting voice is simply ignored. Don't sugar-coat or politicize it like this -- it was rammed down everyone's throats. That is core's right, but don't act as everyone's opinions and concerns were taken into consideration. There are a good number of folks who are concerned that this CoC is overreaching and is ripe for abuse. Those concerns were always simply, plainly, and purposely ignored.
> Please take time to read and understand the CoC, which is intended to ensure that PostgreSQL remains an open and enjoyable project for anyone to join and participate in.
I sincerely hope so, and that it doesn't become a tool to enforce social ideology like in other groups I've been part of. Especially since this is the main place to come to get help for PostgreSQL and not a social club.
Jim
On September 18, 2018 6:27:56 AM EDT, Dave Page <[email protected]<mailto:[email protected]>> wrote:
The PostgreSQL Core team are pleased to announce that following a long consultation process, the project’s Code of Conduct (CoC) has now been finalised and published at https://www.postgresql.org/about/policies/coc/.
Please take time to read and understand the CoC, which is intended to ensure that PostgreSQL remains an open and enjoyable project for anyone to join and participate in.
A Code of Conduct Committee has been formed to handle any complaints. This consists of the following volunteers:
- Stacey Haysler (Chair)
- Lætitia Avrot
- Vik Fearing
- Jonathan Katz
- Ilya Kosmodemiansky
We would like to extend our thanks and gratitude to Stacey Haysler for her patience and expertise in helping develop the Code of Conduct, forming the committee and guiding the work to completion.
--
Dave Page
PostgreSQL Core Team
http://www.postgresql.org/
<http://www.postgresql.org/;
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 17:16 Steve Litt <[email protected]>
parent: ERR ORR <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Steve Litt @ 2018-09-19 17:16 UTC (permalink / raw)
To: [email protected]
On Wed, 19 Sep 2018 16:30:56 +0200
ERR ORR <[email protected]> wrote:
> A CoC will inevitably lead to the project taken over by leftists,
Here we go again.
SteveT
Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 18:02 Francisco Olarte <[email protected]>
parent: Fred Pratt <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Francisco Olarte @ 2018-09-19 18:02 UTC (permalink / raw)
To: Fred Pratt <[email protected]>; +Cc: [email protected] <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>
On Wed, Sep 19, 2018 at 5:27 PM, Fred Pratt
<[email protected]> wrote:
> Keep pg open and free. This smells of PC police. This community can police itself
No comment on this, just kept for context.
> Sent from my mobile device. Please pardon my brevity and typos. I am not responsible for changes made by this device’s autocorrect feature.
I will happily pardon brevity ( although I would not call a ten line
sig plus a huge bottom quote "breve", and AFAIK it means the same in
english as in spanish ) and/or typos, but the "I am not responsible"
feels nearly insulting. Did someone force you to use "this device" (
which you seem to perceive as inadequate for a nice answer ) to reply,
or did you choose to do it ? ( real, not rethoric question, but do not
answer if you feel its inadequate )
As an aside, is this kind of afirmations and/or my response to it a
violation of the current CoC ?
Francisco Olarte.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 18:07 Stephen Frost <[email protected]>
parent: Francisco Olarte <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Stephen Frost @ 2018-09-19 18:07 UTC (permalink / raw)
To: Francisco Olarte <[email protected]>; +Cc: Fred Pratt <[email protected]>; [email protected] <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>
Greetings,
* Francisco Olarte ([email protected]) wrote:
> I will happily pardon brevity ( although I would not call a ten line
> sig plus a huge bottom quote "breve", and AFAIK it means the same in
> english as in spanish ) and/or typos, but the "I am not responsible"
> feels nearly insulting. Did someone force you to use "this device" (
> which you seem to perceive as inadequate for a nice answer ) to reply,
> or did you choose to do it ? ( real, not rethoric question, but do not
> answer if you feel its inadequate )
Let's please try to keep the off-topic discussion on these lists to a
minimum.
> As an aside, is this kind of afirmations and/or my response to it a
> violation of the current CoC ?
There's a way to find out the answer to that question, but it's
certainly not to send an email to this list asking about it. Please
review the policy, and follow the process outlined there if you feel the
need to.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 18:34 Fred Pratt <[email protected]>
parent: Francisco Olarte <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Fred Pratt @ 2018-09-19 18:34 UTC (permalink / raw)
To: Francisco Olarte <[email protected]>; +Cc: [email protected] <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>
Sorry, I emailed using my company account and thus the long sig. In an effort to avoid further insulting Mr Olarte, I will delete it this time. See, Self-policing works !
Fred
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 20:27 Kevin Grittner <[email protected]>
parent: Dave Page <[email protected]>
2 siblings, 1 reply; 35+ messages in thread
From: Kevin Grittner @ 2018-09-19 20:27 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
On Tue, Sep 18, 2018 at 5:28 AM Dave Page <[email protected]> wrote:
>
> The PostgreSQL Core team are pleased to announce that following a long consultation process, the project’s Code of Conduct (CoC) has now been finalised and published at https://www.postgresql.org/about/policies/coc/.
>
> Please take time to read and understand the CoC, which is intended to ensure that PostgreSQL remains an open and enjoyable project for anyone to join and participate in.
>
> A Code of Conduct Committee has been formed to handle any complaints. This consists of the following volunteers:
>
> - Stacey Haysler (Chair)
> - Lætitia Avrot
> - Vik Fearing
> - Jonathan Katz
> - Ilya Kosmodemiansky
>
> We would like to extend our thanks and gratitude to Stacey Haysler for her patience and expertise in helping develop the Code of Conduct, forming the committee and guiding the work to completion.
My thanks to all who participated.
FWIW, my view is that a CoC shares one very important characteristic
with coding style guides: it's not as important what the details are
as that you have one and everyone pays attention to it. I was in an
early PGCon meeting on the topic, and offered some opinions early in
the process, so many of you may remember that my view was to keep it
short and simple -- a wide net with broad mesh, and trust that with
competent application nothing would slip through.
My biggest concern about the current document is that it is hard to
make it from start to end, reading every word. To check my
(admittedly subjective) impression, I put it through the free
"Readability Test Tool" at
https://www.webpagefx.com/tools/read-able/check.php (pasting the
document itself into the "TEST BY DIRECT INPUT" tab so that page
menus, footers, etc. were not included in the score), and got this:
"""
Test Results:
Your text has an average grade level of about 16. It should be easily
understood by 21 to 22 year olds.
"""
Now, on the whole that doesn't sound too bad, since the audience
should be mature and educated enough to deal with that, but it does
suggest that it might be a bit of a burden on some for whom English is
not their first language (unless we have translations?).
Further detail:
"""
Readability Indices
Flesch Kincaid Reading Ease 32.2
Flesch Kincaid Grade Level 15.2
Gunning Fog Score 18.3
SMOG Index 13.9
Coleman Liau Index 14.8
Automated Readability Index 16
Text Statistics
No. of sentences 65
No. of words 1681
No. of complex words 379
Percent of complex words 22.55%
Average words per sentence 25.86
Average syllables per word 1.75
"""
Note that the page mentions that the Flesch Kincaid Reading Ease score
is based on a 0-100 scale. A high score means the text is easier to
read. Low scores suggest the text is complicated to understand. A
value between 60 and 80 should be easy for a 12 to 15 year old to
understand. Our score was 32.2.
Perhaps in next year's review we could try to ease this a little.
In the meantime, I was very happy to see the so many new faces at
PostgresOpen SV 2018; maybe it's just a happy coincidence, but if this
effort had anything to do with drawing in more people, it was well
worth the effort!
Kevin Grittner
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 20:44 Andrew Dunstan <[email protected]>
parent: Kevin Grittner <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Andrew Dunstan @ 2018-09-19 20:44 UTC (permalink / raw)
To: Kevin Grittner <[email protected]>; [email protected]; +Cc: [email protected]; [email protected]
On 09/19/2018 04:27 PM, Kevin Grittner wrote:
> On Tue, Sep 18, 2018 at 5:28 AM Dave Page <[email protected]> wrote:
>> The PostgreSQL Core team are pleased to announce that following a long consultation process, the project’s Code of Conduct (CoC) has now been finalised and published at https://www.postgresql.org/about/policies/coc/.
>>
>> Please take time to read and understand the CoC, which is intended to ensure that PostgreSQL remains an open and enjoyable project for anyone to join and participate in.
>>
>> A Code of Conduct Committee has been formed to handle any complaints. This consists of the following volunteers:
>>
>> - Stacey Haysler (Chair)
>> - Lætitia Avrot
>> - Vik Fearing
>> - Jonathan Katz
>> - Ilya Kosmodemiansky
>>
>> We would like to extend our thanks and gratitude to Stacey Haysler for her patience and expertise in helping develop the Code of Conduct, forming the committee and guiding the work to completion.
> My thanks to all who participated.
Indeed, many thanks.
[...]
> In the meantime, I was very happy to see the so many new faces at
> PostgresOpen SV 2018; maybe it's just a happy coincidence, but if this
> effort had anything to do with drawing in more people, it was well
> worth the effort!
>
Yeah. The crowd also seemed noticeably more diverse than I have usually
seen at Postgres conferences. That's a small beginning, but it's a
welcome development.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-19 21:30 Bruce Momjian <[email protected]>
parent: Julian Paul <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Bruce Momjian @ 2018-09-19 21:30 UTC (permalink / raw)
To: Julian Paul <[email protected]>; +Cc: [email protected]
On Wed, Sep 19, 2018 at 11:24:29AM +1000, Julian Paul wrote:
> It's overly long and convoluted.
>
> "inclusivity" Is a ideologue buzzword of particular individuals that offer
> very little value apart from excessive policing of speech and behaviour
> assumed to be a problem where none exist.
>
> "Personal attacks and negative comments on personal characteristics are
> unacceptable, and will not be permitted. Examples of personal
> characteristics include, but are not limited to age, race, national origin
> or ancestry, religion, gender, or sexual orientation."
>
> So just leaving it at "Personal attacks" and ending it there won't do
> obviously. I'm a big advocate of people sorting out there own personal
> disputes in private but...
>
> "further personal attacks (public or *private*);"
>
> ...lets assume people don't have the maturity for that and make it all
> public.
>
> "may be considered offensive by fellow members" - Purely subjective and
> irrelevant to a piece of community software.
You might notice that a bullet list was removed and those example items
were added 18 months ago:
https://wiki.postgresql.org/index.php?title=Code_of_Conduct&diff=31924&oldid=29402
I realize that putting no examples has its attractions, but some felt
that having examples would be helpful. I am not a big fan of the
"protected groups" concept because it is often exploited, which is why
they are listed more as examples.
--
Bruce Momjian <[email protected]> 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 +
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-20 15:20 Chris Travers <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Chris Travers @ 2018-09-20 15:20 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: [email protected]; pgsql-generallists.postgresql.org <[email protected]>
On Wed, Sep 19, 2018 at 11:31 PM Bruce Momjian <[email protected]> wrote:
> On Wed, Sep 19, 2018 at 11:24:29AM +1000, Julian Paul wrote:
> > It's overly long and convoluted.
> >
> > "inclusivity" Is a ideologue buzzword of particular individuals that
> offer
> > very little value apart from excessive policing of speech and behaviour
> > assumed to be a problem where none exist.
> >
> > "Personal attacks and negative comments on personal characteristics are
> > unacceptable, and will not be permitted. Examples of personal
> > characteristics include, but are not limited to age, race, national
> origin
> > or ancestry, religion, gender, or sexual orientation."
> >
> > So just leaving it at "Personal attacks" and ending it there won't do
> > obviously. I'm a big advocate of people sorting out there own personal
> > disputes in private but...
> >
> > "further personal attacks (public or *private*);"
> >
> > ...lets assume people don't have the maturity for that and make it all
> > public.
> >
> > "may be considered offensive by fellow members" - Purely subjective and
> > irrelevant to a piece of community software.
>
> You might notice that a bullet list was removed and those example items
> were added 18 months ago:
>
>
> https://wiki.postgresql.org/index.php?title=Code_of_Conduct&diff=31924&oldid=29402
>
> I realize that putting no examples has its attractions, but some felt
> that having examples would be helpful. I am not a big fan of the
> "protected groups" concept because it is often exploited, which is why
> they are listed more as examples.
>
I suspect most of us could probably get behind the groups listed in the
antidiscrimination section of the European Charter of Fundamental Rights at
least as a compromise.
Quoting the English version:
"Any discrimination based on any ground such as sex, race, colour, ethnic
or social origin, genetic features, language, religion or belief, political
or any other opinion, membership of a national minority, property, birth,
disability, age or sexual orientation shall be prohibited."
The inclusion of "political or any other opinion" is a nice addition and
prevents a lot of concern.
>
> --
> Bruce Momjian <[email protected]> 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 +
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-20 20:13 Bruce Momjian <[email protected]>
parent: Chris Travers <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Bruce Momjian @ 2018-09-20 20:13 UTC (permalink / raw)
To: Chris Travers <[email protected]>; +Cc: [email protected]; pgsql-generallists.postgresql.org <[email protected]>
On Thu, Sep 20, 2018 at 05:20:55PM +0200, Chris Travers wrote:
> I suspect most of us could probably get behind the groups listed in the
> antidiscrimination section of the European Charter of Fundamental Rights at
> least as a compromise.
>
> Quoting the English version:
>
> "Any discrimination based on any ground such as sex, race, colour, ethnic or
> social origin, genetic features, language, religion or belief, political or any
> other opinion, membership of a national minority, property, birth, disability,
> age or sexual orientation shall be prohibited."
>
> The inclusion of "political or any other opinion" is a nice addition and
> prevents a lot of concern.
Huh. Certainly something to consider when we review the CoC in a year.
--
Bruce Momjian <[email protected]> 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 +
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Code of Conduct
@ 2018-09-21 02:23 Stephen Cook <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Stephen Cook @ 2018-09-21 02:23 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Chris Travers <[email protected]>; +Cc: [email protected]; pgsql-generallists.postgresql.org <[email protected]>
On 2018-09-20 16:13, Bruce Momjian wrote:
> On Thu, Sep 20, 2018 at 05:20:55PM +0200, Chris Travers wrote:
>> I suspect most of us could probably get behind the groups listed in the
>> antidiscrimination section of the European Charter of Fundamental Rights at
>> least as a compromise.
>>
>> Quoting the English version:
>>
>> "Any discrimination based on any ground such as sex, race, colour, ethnic or
>> social origin, genetic features, language, religion or belief, political or any
>> other opinion, membership of a national minority, property, birth, disability,
>> age or sexual orientation shall be prohibited."
>>
>> The inclusion of "political or any other opinion" is a nice addition and
>> prevents a lot of concern.
>
> Huh. Certainly something to consider when we review the CoC in a year.
>
Too bad it wasn't brought up earlier.
-- Stephen
^ permalink raw reply [nested|flat] 35+ messages in thread
* [PATCH v2 12/12] docs: create or reindex progress of ptn tables
@ 2019-04-05 00:39 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Justin Pryzby @ 2019-04-05 00:39 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index a1c3848..5ada8b7 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -3582,16 +3582,16 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<entry><structfield>partitions_total</structfield></entry>
<entry><type>bigint</type></entry>
<entry>
- When creating an index on a partitioned table, this column is set to
- the total number of partitions on which the index is to be created.
+ When the index being created or reindexed is on a partitioned table,
+ this is the total number of partitions to be processed.
</entry>
</row>
<row>
<entry><structfield>partitions_done</structfield></entry>
<entry><type>bigint</type></entry>
<entry>
- When creating an index on a partitioned table, this column is set to
- the number of partitions on which the index has been completed.
+ When the index being created or reindexed is on a partitioned table,
+ this is the number of partitions for which the process is complete.
</entry>
</row>
</tbody>
--
2.1.4
--u65IjBhB3TIa72Vp--
^ permalink raw reply [nested|flat] 35+ messages in thread
* [PATCH v3 2/2] add timing information to pg_upgrade
@ 2023-07-27 23:16 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Nathan Bossart @ 2023-07-27 23:16 UTC (permalink / raw)
---
src/bin/pg_upgrade/util.c | 55 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/util.c b/src/bin/pg_upgrade/util.c
index 21ba4c8f12..23fd5f87af 100644
--- a/src/bin/pg_upgrade/util.c
+++ b/src/bin/pg_upgrade/util.c
@@ -9,14 +9,19 @@
#include "postgres_fe.h"
+#include <math.h>
#include <signal.h>
#include "common/username.h"
#include "pg_upgrade.h"
+#include "portability/instr_time.h"
LogOpts log_opts;
+static instr_time step_start;
+
static void pg_log_v(eLogType type, const char *fmt, va_list ap) pg_attribute_printf(2, 0);
+static char *get_time_str(double time_ms);
/*
@@ -137,6 +142,8 @@ prep_status(const char *fmt,...)
/* trim strings */
pg_log(PG_REPORT_NONL, "%-*s", MESSAGE_WIDTH, message);
+
+ INSTR_TIME_SET_CURRENT(step_start);
}
/*
@@ -170,6 +177,8 @@ prep_status_progress(const char *fmt,...)
pg_log(PG_REPORT, "%-*s", MESSAGE_WIDTH, message);
else
pg_log(PG_REPORT_NONL, "%-*s", MESSAGE_WIDTH, message);
+
+ INSTR_TIME_SET_CURRENT(step_start);
}
static void
@@ -280,11 +289,55 @@ pg_fatal(const char *fmt,...)
}
+static char *
+get_time_str(double time_ms)
+{
+ double seconds;
+ double minutes;
+ double hours;
+ double days;
+
+ if (time_ms < 1000.0)
+ return psprintf(_("%.3f ms"), time_ms);
+
+ seconds = time_ms / 1000.0;
+ minutes = floor(seconds / 60.0);
+ seconds -= 60.0 * minutes;
+ if (minutes < 60.0)
+ return psprintf(_("%.3f ms (%02d:%06.3f)"),
+ time_ms, (int) minutes, seconds);
+
+ hours = floor(minutes / 60.0);
+ minutes -= 60.0 * hours;
+ if (hours < 24.0)
+ return psprintf(_("%.3f ms (%02d:%02d:%06.3f)"),
+ time_ms, (int) hours, (int) minutes, seconds);
+
+ days = floor(hours / 24.0);
+ hours -= 24.0 * days;
+ return psprintf(_("%.3f ms (%.0f d %02d:%02d:%06.3f)"),
+ time_ms, days, (int) hours, (int) minutes, seconds);
+}
+
+
void
check_ok(void)
{
+ instr_time step_end;
+ char *step_time;
+
+ Assert(!INSTR_TIME_IS_ZERO(step_start));
+
+ INSTR_TIME_SET_CURRENT(step_end);
+ INSTR_TIME_SUBTRACT(step_end, step_start);
+ step_time = get_time_str(INSTR_TIME_GET_MILLISEC(step_end));
+
+ /* reset start time */
+ INSTR_TIME_SET_ZERO(step_start);
+
/* all seems well */
- report_status(PG_REPORT, "ok");
+ report_status(PG_REPORT, "ok\t%s", step_time);
+ pfree(step_time);
}
--
2.25.1
--AhhlLboLdkugWU4S--
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-06-25 17:48 David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: David E. Wheeler @ 2024-06-25 17:48 UTC (permalink / raw)
To: Степан Неретин <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jun 25, 2024, at 12:46 AM, Степан Неретин <[email protected]> wrote:
> Hi! Looks good to me, but I have several comments.
Thanks for your review!
> Your patch improves tests, but why did you change formatting in jsonpath_exec.c? What's the motivation?
It’s not just formatting. From the commit message:
> While at it, teach `executeAnyItem()` to return `jperOk` when `found`
> exist, not because it will be used (the result and `found` are inspected
> by different functions), but because it seems like the proper thing to
> return from `executeAnyItem()` when considered in isolation.
I have since realized it’s not a complete fix for the issue, and hacked around it in my Go version. Would be fine to remove that bit, but IIRC this was the only execution function that would return `jperNotFound` when it in fact adds items to the `found` list. The current implementation only looks at one or the other, so it’s not super important, but I found the inconsistency annoying and sometimes confusing.
> [1] select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
> I propose adding a similar test with explicitly specified lax mode: select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*'); to show what lax mode is set by default.
Very few of the other tests do so; I can add it if it’s important for this case, though.
> Odd empty result for the test: select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'strict $.*';
> I expected an error like in test [1]. This behavior is not obvious to me.
@? suppresses a number of errors. Perhaps I should add a variant of the error-raising query that passes the silent arg, which would also suppress the error.
> Everything else is cool. Thanks to the patch and the discussion above, I began to understand better how wildcards in JSON work.
Yeah, it’s kind of wild TBH.
Best,
David
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-06-26 18:16 David E. Wheeler <[email protected]>
parent: David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: David E. Wheeler @ 2024-06-26 18:16 UTC (permalink / raw)
To: Степан Неретин <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jun 25, 2024, at 13:48, David E. Wheeler <[email protected]> wrote:
> I have since realized it’s not a complete fix for the issue, and hacked around it in my Go version. Would be fine to remove that bit, but IIRC this was the only execution function that would return `jperNotFound` when it in fact adds items to the `found` list. The current implementation only looks at one or the other, so it’s not super important, but I found the inconsistency annoying and sometimes confusing.
I’ve removed this change.
>> [1] select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
>> I propose adding a similar test with explicitly specified lax mode: select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*'); to show what lax mode is set by default.
>
> Very few of the other tests do so; I can add it if it’s important for this case, though.
Went ahead and added lax.
> @? suppresses a number of errors. Perhaps I should add a variant of the error-raising query that passes the silent arg, which would also suppress the error.
Added a variant where the silent param suppresses the error, too.
V2 attached and the PR updated:
https://github.com/theory/postgres/pull/4/files
Best,
David
Attachments:
[application/octet-stream] v2-0001-Add-tests-for-jsonpath-.-on-arrays.patch (4.1K, ../../[email protected]/2-v2-0001-Add-tests-for-jsonpath-.-on-arrays.patch)
download | inline diff:
From a7f9c1e4261d4279a4b38ba8ef903cc0e0707ca5 Mon Sep 17 00:00:00 2001
From: "David E. Wheeler" <[email protected]>
Date: Wed, 26 Jun 2024 14:12:47 -0400
Subject: [PATCH v2] Add tests for jsonpath `.*` on arrays
There was no coverage for the path to unwrap an array before applying
`.*` to it, so add tests that explicitly test `.*` for both objects and
arrays, showing how no results are returned for an array of scalars, but
results are returned when the array contains an object. Also test the
behavior in strict mode with and without the silent parameter, and with
the `@?` operator.
Unrelated but potentially useful to future source readers: document
`GetJsonPathVar` and `CountJsonPathVars`.
---
src/backend/utils/adt/jsonpath_exec.c | 7 ++-
src/test/regress/expected/jsonb_jsonpath.out | 50 ++++++++++++++++++++
src/test/regress/sql/jsonb_jsonpath.sql | 11 +++++
3 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/src/backend/utils/adt/jsonpath_exec.c b/src/backend/utils/adt/jsonpath_exec.c
index d79c929822..bf69f0d824 100644
--- a/src/backend/utils/adt/jsonpath_exec.c
+++ b/src/backend/utils/adt/jsonpath_exec.c
@@ -2978,7 +2978,8 @@ getJsonPathItem(JsonPathExecContext *cxt, JsonPathItem *item,
}
/*
- * Returns the computed value of a JSON path variable with given name.
+ * Definition of JsonPathGetVarCallback for when JsonPathExecContext.vars
+ * is specified as a List value.
*/
static JsonbValue *
GetJsonPathVar(void *cxt, char *varName, int varNameLen,
@@ -3025,6 +3026,10 @@ GetJsonPathVar(void *cxt, char *varName, int varNameLen,
return result;
}
+/*
+ * Definition of JsonPathCountVarsCallback for when JsonPathExecContext.vars
+ * is specified as a List value.
+ */
static int
CountJsonPathVars(void *cxt)
{
diff --git a/src/test/regress/expected/jsonb_jsonpath.out b/src/test/regress/expected/jsonb_jsonpath.out
index a6112e86fa..3dea937887 100644
--- a/src/test/regress/expected/jsonb_jsonpath.out
+++ b/src/test/regress/expected/jsonb_jsonpath.out
@@ -4394,3 +4394,53 @@ ORDER BY s1.num, s2.num;
{"s": "B"} | {"s": "B"} | false | true | true | true | false
(144 rows)
+-- Test any key on arrays with and without unwrapping.
+select jsonb_path_query('{"a": [1,2,3], "b": [3,4,5]}', '$.*');
+ jsonb_path_query
+------------------
+ [1, 2, 3]
+ [3, 4, 5]
+(2 rows)
+
+select jsonb_path_query('[1,2,3]', '$.*');
+ jsonb_path_query
+------------------
+(0 rows)
+
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*');
+ jsonb_path_query
+------------------
+ [3, 4, 5]
+(1 row)
+
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
+ERROR: jsonpath wildcard member accessor can only be applied to an object
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*', NULL, true);
+ jsonb_path_query
+------------------
+(0 rows)
+
+select jsonb '{"a": [1,2,3], "b": [3,4,5]}' @? '$.*';
+ ?column?
+----------
+ t
+(1 row)
+
+select jsonb '[1,2,3]' @? '$.*';
+ ?column?
+----------
+ f
+(1 row)
+
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'lax $.*';
+ ?column?
+----------
+ t
+(1 row)
+
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'strict $.*';
+ ?column?
+----------
+
+(1 row)
+
diff --git a/src/test/regress/sql/jsonb_jsonpath.sql b/src/test/regress/sql/jsonb_jsonpath.sql
index 5e14f7759b..f60bccc654 100644
--- a/src/test/regress/sql/jsonb_jsonpath.sql
+++ b/src/test/regress/sql/jsonb_jsonpath.sql
@@ -1116,3 +1116,14 @@ SELECT
jsonb_path_query_first(s1.j, '$.s > $s', vars => s2.j) gt
FROM str s1, str s2
ORDER BY s1.num, s2.num;
+
+-- Test any key on arrays with and without unwrapping.
+select jsonb_path_query('{"a": [1,2,3], "b": [3,4,5]}', '$.*');
+select jsonb_path_query('[1,2,3]', '$.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*', NULL, true);
+select jsonb '{"a": [1,2,3], "b": [3,4,5]}' @? '$.*';
+select jsonb '[1,2,3]' @? '$.*';
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'lax $.*';
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'strict $.*';
--
2.45.2
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-06-27 04:53 Stepan Neretin <[email protected]>
parent: David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Stepan Neretin @ 2024-06-27 04:53 UTC (permalink / raw)
To: David E. Wheeler <[email protected]>; +Cc: Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Thu, Jun 27, 2024 at 1:16 AM David E. Wheeler <[email protected]>
wrote:
> On Jun 25, 2024, at 13:48, David E. Wheeler <[email protected]> wrote:
>
> > I have since realized it’s not a complete fix for the issue, and hacked
> around it in my Go version. Would be fine to remove that bit, but IIRC this
> was the only execution function that would return `jperNotFound` when it in
> fact adds items to the `found` list. The current implementation only looks
> at one or the other, so it’s not super important, but I found the
> inconsistency annoying and sometimes confusing.
>
> I’ve removed this change.
>
> >> [1] select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
> >> I propose adding a similar test with explicitly specified lax mode:
> select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*'); to show what
> lax mode is set by default.
> >
> > Very few of the other tests do so; I can add it if it’s important for
> this case, though.
>
> Went ahead and added lax.
>
> > @? suppresses a number of errors. Perhaps I should add a variant of the
> error-raising query that passes the silent arg, which would also suppress
> the error.
>
> Added a variant where the silent param suppresses the error, too.
>
> V2 attached and the PR updated:
>
> https://github.com/theory/postgres/pull/4/files
>
> Best,
>
> David
>
>
>
>
HI! Now it looks good for me.
Best regards, Stepan Neretin.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-06-27 08:17 Michael Paquier <[email protected]>
parent: Stepan Neretin <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Michael Paquier @ 2024-06-27 08:17 UTC (permalink / raw)
To: Stepan Neretin <[email protected]>; +Cc: David E. Wheeler <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Thu, Jun 27, 2024 at 11:53:14AM +0700, Stepan Neretin wrote:
> HI! Now it looks good for me.
The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
jsonb_path_query with the lax and strict modes, so shouldn't these
additions be grouped closer to the existing tests rather than added at
the end of the file?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-06-27 15:05 David E. Wheeler <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: David E. Wheeler @ 2024-06-27 15:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jun 27, 2024, at 04:17, Michael Paquier <[email protected]> wrote:
> The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> jsonb_path_query with the lax and strict modes, so shouldn't these
> additions be grouped closer to the existing tests rather than added at
> the end of the file?
I think you could argue that they should go with other tests for array unwrapping, though it’s kind of mixed throughout. But that’s more the bit I was testing; almost all the tests are lax, and it’s less the strict behavior to test here than the explicit behavior of unwrapping in lax mode.
But ultimately I don’t care where they go, just that we have them.
D
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-08 16:09 David E. Wheeler <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: David E. Wheeler @ 2024-07-08 16:09 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jun 27, 2024, at 04:17, Michael Paquier <[email protected]> wrote:
> The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> jsonb_path_query with the lax and strict modes, so shouldn't these
> additions be grouped closer to the existing tests rather than added at
> the end of the file?
I’ve moved them closer to other tests for unwrapping behavior in the attached updated and rebased v3 patch.
Best,
David
Attachments:
[application/octet-stream] v3-0001-Add-tests-for-jsonpath-.-on-arrays.patch (4.3K, ../../[email protected]/2-v3-0001-Add-tests-for-jsonpath-.-on-arrays.patch)
download | inline diff:
From eefe7a08e7c365082954c0026a13dad41f713744 Mon Sep 17 00:00:00 2001
From: "David E. Wheeler" <[email protected]>
Date: Mon, 8 Jul 2024 12:08:00 -0400
Subject: [PATCH v3] Add tests for jsonpath `.*` on arrays
There was no coverage for the path to unwrap an array before applying
`.*` to it, so add tests that explicitly test `.*` for both objects and
arrays, showing how no results are returned for an array of scalars, but
results are returned when the array contains an object. Also test the
behavior in strict mode with and without the silent parameter, and with
the `@?` operator.
Unrelated but potentially useful to future source readers: document
`GetJsonPathVar` and `CountJsonPathVars`.
---
src/backend/utils/adt/jsonpath_exec.c | 7 ++-
src/test/regress/expected/jsonb_jsonpath.out | 50 ++++++++++++++++++++
src/test/regress/sql/jsonb_jsonpath.sql | 11 +++++
3 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/src/backend/utils/adt/jsonpath_exec.c b/src/backend/utils/adt/jsonpath_exec.c
index d79c929822..bf69f0d824 100644
--- a/src/backend/utils/adt/jsonpath_exec.c
+++ b/src/backend/utils/adt/jsonpath_exec.c
@@ -2978,7 +2978,8 @@ getJsonPathItem(JsonPathExecContext *cxt, JsonPathItem *item,
}
/*
- * Returns the computed value of a JSON path variable with given name.
+ * Definition of JsonPathGetVarCallback for when JsonPathExecContext.vars
+ * is specified as a List value.
*/
static JsonbValue *
GetJsonPathVar(void *cxt, char *varName, int varNameLen,
@@ -3025,6 +3026,10 @@ GetJsonPathVar(void *cxt, char *varName, int varNameLen,
return result;
}
+/*
+ * Definition of JsonPathCountVarsCallback for when JsonPathExecContext.vars
+ * is specified as a List value.
+ */
static int
CountJsonPathVars(void *cxt)
{
diff --git a/src/test/regress/expected/jsonb_jsonpath.out b/src/test/regress/expected/jsonb_jsonpath.out
index a6112e86fa..7bb4eb1bc2 100644
--- a/src/test/regress/expected/jsonb_jsonpath.out
+++ b/src/test/regress/expected/jsonb_jsonpath.out
@@ -1135,6 +1135,56 @@ select jsonb_path_query('{"a": [1, 2]}', 'lax $.a * 3', silent => true);
------------------
(0 rows)
+-- any key on arrays with and without unwrapping.
+select jsonb_path_query('{"a": [1,2,3], "b": [3,4,5]}', '$.*');
+ jsonb_path_query
+------------------
+ [1, 2, 3]
+ [3, 4, 5]
+(2 rows)
+
+select jsonb_path_query('[1,2,3]', '$.*');
+ jsonb_path_query
+------------------
+(0 rows)
+
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*');
+ jsonb_path_query
+------------------
+ [3, 4, 5]
+(1 row)
+
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
+ERROR: jsonpath wildcard member accessor can only be applied to an object
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*', NULL, true);
+ jsonb_path_query
+------------------
+(0 rows)
+
+select jsonb '{"a": [1,2,3], "b": [3,4,5]}' @? '$.*';
+ ?column?
+----------
+ t
+(1 row)
+
+select jsonb '[1,2,3]' @? '$.*';
+ ?column?
+----------
+ f
+(1 row)
+
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'lax $.*';
+ ?column?
+----------
+ t
+(1 row)
+
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'strict $.*';
+ ?column?
+----------
+
+(1 row)
+
-- extension: boolean expressions
select jsonb_path_query('2', '$ > 1');
jsonb_path_query
diff --git a/src/test/regress/sql/jsonb_jsonpath.sql b/src/test/regress/sql/jsonb_jsonpath.sql
index 5e14f7759b..17f9d038c0 100644
--- a/src/test/regress/sql/jsonb_jsonpath.sql
+++ b/src/test/regress/sql/jsonb_jsonpath.sql
@@ -241,6 +241,17 @@ select jsonb_path_query('{"a": [2, 3, 4]}', 'lax -$.a');
select jsonb_path_query('{"a": [1, 2]}', 'lax $.a * 3');
select jsonb_path_query('{"a": [1, 2]}', 'lax $.a * 3', silent => true);
+-- any key on arrays with and without unwrapping.
+select jsonb_path_query('{"a": [1,2,3], "b": [3,4,5]}', '$.*');
+select jsonb_path_query('[1,2,3]', '$.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'lax $.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*');
+select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', 'strict $.*', NULL, true);
+select jsonb '{"a": [1,2,3], "b": [3,4,5]}' @? '$.*';
+select jsonb '[1,2,3]' @? '$.*';
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'lax $.*';
+select jsonb '[1,2,3,{"b": [3,4,5]}]' @? 'strict $.*';
+
-- extension: boolean expressions
select jsonb_path_query('2', '$ > 1');
select jsonb_path_query('2', '$ <= 1');
--
2.45.2
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-15 11:07 Stepan Neretin <[email protected]>
parent: David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Stepan Neretin @ 2024-07-15 11:07 UTC (permalink / raw)
To: David E. Wheeler <[email protected]>; +Cc: Michael Paquier <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Mon, Jul 8, 2024 at 11:09 PM David E. Wheeler <[email protected]>
wrote:
> On Jun 27, 2024, at 04:17, Michael Paquier <[email protected]> wrote:
>
> > The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> > jsonb_path_query with the lax and strict modes, so shouldn't these
> > additions be grouped closer to the existing tests rather than added at
> > the end of the file?
>
> I’ve moved them closer to other tests for unwrapping behavior in the
> attached updated and rebased v3 patch.
>
> Best,
>
> David
>
>
>
Hi! Looks good to me now! Please, register a patch in CF.
Best regards, Stepan Neretin.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-15 14:29 David E. Wheeler <[email protected]>
parent: Stepan Neretin <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: David E. Wheeler @ 2024-07-15 14:29 UTC (permalink / raw)
To: Stepan Neretin <[email protected]>; +Cc: Michael Paquier <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jul 15, 2024, at 07:07, Stepan Neretin <[email protected]> wrote:
> Hi! Looks good to me now! Please, register a patch in CF.
> Best regards, Stepan Neretin.
It’s here:
https://commitfest.postgresql.org/48/5017/
Best,
David
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-19 05:42 Michael Paquier <[email protected]>
parent: David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Michael Paquier @ 2024-07-19 05:42 UTC (permalink / raw)
To: David E. Wheeler <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Mon, Jul 15, 2024 at 10:29:32AM -0400, David E. Wheeler wrote:
> It’s here:
>
> https://commitfest.postgresql.org/48/5017/
Sorry for the delay. Finally came back to it, and applied the tests.
Thanks!
It was fun to see that HEAD was silenced with the first patch of this
thread that tweaked the behavior with arrays.
Regarding the comments, I have left them out for now. That may be a
good start, but it also feels like we should do a much better job
overall with the area of jsonpath_exec.c. One thing that may help as
a start is to reorganize the routines of the file and divide them into
sub-categories, or even go through a deeper refactoring to help
readers go through the existing 4.5k lines of code that are in this
single file..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-19 13:49 David E. Wheeler <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: David E. Wheeler @ 2024-07-19 13:49 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jul 19, 2024, at 01:42, Michael Paquier <[email protected]> wrote:
> Sorry for the delay. Finally came back to it, and applied the tests.
> Thanks!
Awesome, thank you!
> It was fun to see that HEAD was silenced with the first patch of this
> thread that tweaked the behavior with arrays.
Uh, what? Sorry I don’t follow.
> Regarding the comments, I have left them out for now. That may be a
> good start, but it also feels like we should do a much better job
> overall with the area of jsonpath_exec.c.
I put them in because it took me a bit to track down that they were among the implementors of JsonPathGetVarCallback as I was porting the code.
> One thing that may help as
> a start is to reorganize the routines of the file and divide them into
> sub-categories, or even go through a deeper refactoring to help
> readers go through the existing 4.5k lines of code that are in this
> single file..
After I got all the tests passing in the port to Go, I split it up into 14 implementation and 15 test files (with all of jsonb_jsonpath.(sql.out) in one file). Was much easier to reason about that way.
https://github.com/theory/sqljson/tree/main/path/exec
Best,
David
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-22 00:54 Michael Paquier <[email protected]>
parent: David E. Wheeler <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Michael Paquier @ 2024-07-22 00:54 UTC (permalink / raw)
To: David E. Wheeler <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Fri, Jul 19, 2024 at 09:49:50AM -0400, David E. Wheeler wrote:
>> It was fun to see that HEAD was silenced with the first patch of this
>> thread that tweaked the behavior with arrays.
>
> Uh, what? Sorry I don’t follow.
What I mean is that the main regression test suite did not complain on
your original patch posted here:
https://www.postgresql.org/message-id/A95346F9-6147-46E0-809E-532A485D71D6%40justatheory.com
But the new tests showed a difference, and that's enough for me to see
value in the new tests.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Patch bug: Fix jsonpath .* on Arrays
@ 2024-07-22 02:18 David E. Wheeler <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: David E. Wheeler @ 2024-07-22 02:18 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Stepan Neretin <[email protected]>; Степан Неретин <[email protected]>; PostgreSQL Hackers <[email protected]>; David G. Johnston <[email protected]>
On Jul 21, 2024, at 20:54, Michael Paquier <[email protected]> wrote:
> What I mean is that the main regression test suite did not complain on
> your original patch posted here:
> https://www.postgresql.org/message-id/A95346F9-6147-46E0-809E-532A485D71D6%40justatheory.com
>
> But the new tests showed a difference, and that's enough for me to see
> value in the new tests.
Oh, got it, nice!
Thanks,
David
^ permalink raw reply [nested|flat] 35+ messages in thread
end of thread, other threads:[~2024-07-22 02:18 UTC | newest]
Thread overview: 35+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-09-18 10:27 Code of Conduct Dave Page <[email protected]>
2018-09-18 11:47 ` James Keener <[email protected]>
2018-09-18 14:34 ` Tomas Vondra <[email protected]>
2018-09-18 16:27 ` James Keener <[email protected]>
2018-09-18 17:08 ` Chris Travers <[email protected]>
2018-09-18 17:14 ` Stephen Frost <[email protected]>
2018-09-18 18:35 ` Tom Lane <[email protected]>
2018-09-18 18:40 ` Chris Travers <[email protected]>
2018-09-19 14:30 ` ERR ORR <[email protected]>
2018-09-19 15:27 ` Fred Pratt <[email protected]>
2018-09-19 18:02 ` Francisco Olarte <[email protected]>
2018-09-19 18:07 ` Stephen Frost <[email protected]>
2018-09-19 18:34 ` Fred Pratt <[email protected]>
2018-09-19 17:16 ` Steve Litt <[email protected]>
2018-09-19 01:24 ` Julian Paul <[email protected]>
2018-09-19 21:30 ` Bruce Momjian <[email protected]>
2018-09-20 15:20 ` Chris Travers <[email protected]>
2018-09-20 20:13 ` Bruce Momjian <[email protected]>
2018-09-21 02:23 ` Stephen Cook <[email protected]>
2018-09-19 20:27 ` Kevin Grittner <[email protected]>
2018-09-19 20:44 ` Andrew Dunstan <[email protected]>
2019-04-05 00:39 [PATCH v2 12/12] docs: create or reindex progress of ptn tables Justin Pryzby <[email protected]>
2023-07-27 23:16 [PATCH v3 2/2] add timing information to pg_upgrade Nathan Bossart <[email protected]>
2024-06-25 17:48 Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-06-26 18:16 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-06-27 04:53 ` Re: Patch bug: Fix jsonpath .* on Arrays Stepan Neretin <[email protected]>
2024-06-27 08:17 ` Re: Patch bug: Fix jsonpath .* on Arrays Michael Paquier <[email protected]>
2024-06-27 15:05 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-07-08 16:09 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-07-15 11:07 ` Re: Patch bug: Fix jsonpath .* on Arrays Stepan Neretin <[email protected]>
2024-07-15 14:29 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-07-19 05:42 ` Re: Patch bug: Fix jsonpath .* on Arrays Michael Paquier <[email protected]>
2024-07-19 13:49 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
2024-07-22 00:54 ` Re: Patch bug: Fix jsonpath .* on Arrays Michael Paquier <[email protected]>
2024-07-22 02:18 ` Re: Patch bug: Fix jsonpath .* on Arrays David E. Wheeler <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox