On 2015-03-18 14:01:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Seriously? In my opinion it has to be possible to doubt whether a patch
> > should be committed in certain release without it being interpreted as a
> > personal attack.
>
> I don't think anyone's said anything in this thre
On Wed, Mar 18, 2015 at 2:01 PM, Tom Lane wrote:
> Andres Freund writes:
>> Seriously? In my opinion it has to be possible to doubt whether a patch
>> should be committed in certain release without it being interpreted as a
>> personal attack.
>
> I don't think anyone's said anything in this thre
Andres Freund writes:
> Seriously? In my opinion it has to be possible to doubt whether a patch
> should be committed in certain release without it being interpreted as a
> personal attack.
I don't think anyone's said anything in this thread that amounts to a
personal attack. We have a differenc
On Wed, Mar 18, 2015 at 10:26 AM, Andres Freund wrote:
> On 2015-03-18 13:12:11 -0400, Tom Lane wrote:
>> Indeed. In this case, since the patch in question is one that
>> improves/simplifies a patch that's already in the current commitfest,
>> I'm going to go ahead and push it. If you want to ca
On 2015-03-18 13:12:11 -0400, Tom Lane wrote:
> Indeed. In this case, since the patch in question is one that
> improves/simplifies a patch that's already in the current commitfest,
> I'm going to go ahead and push it. If you want to call a vote on
> revoking my commit bit, go right ahead.
Serio
On Wed, Mar 18, 2015 at 1:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
>>> Basically, the same rules apply to all commitfests, i.e. a committer can
>>> apply anything during that period. I think the only restriction for the
>>> last commi
Robert Haas writes:
> On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
>> Basically, the same rules apply to all commitfests, i.e. a committer can
>> apply anything during that period. I think the only restriction for the
>> last commitfest is that the committer can not apply a new patch th
On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
> On Tue, Mar 17, 2015 at 04:21:16PM -0700, Peter Geoghegan wrote:
>> I, as a non-committer, have proposed that the rules be bent once or
>> twice in the past, and those suggestions were rejected without
>> exception, even though I imagined tha
On Tue, Mar 17, 2015 at 04:21:16PM -0700, Peter Geoghegan wrote:
> I, as a non-committer, have proposed that the rules be bent once or
> twice in the past, and those suggestions were rejected without
> exception, even though I imagined that there was a compelling
> cost/benefit ratio. I thought tha
On Tue, Mar 17, 2015 at 3:50 PM, Robert Haas wrote:
>> In any case, I reject the notion that the CF process has anything to
>> do with that decision. The point of the CF submission deadline is
>> that we promise to consider every submission made before the deadline.
>> It is not to forbid committ
On Tue, Mar 17, 2015 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
>>> We do have a process in which even committers have to think twice about
>>> whether it's appropriate to push something, but that's feature freeze
>>> during alpha/beta/R
Robert Haas writes:
> On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
>> We do have a process in which even committers have to think twice about
>> whether it's appropriate to push something, but that's feature freeze
>> during alpha/beta/RC testing, and we are still a long way away from that
>>
On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> What I was complaining about is new feature patches for 9.5 arriving
>> after the start of the last CF. There has to be some date after which
>> a patch is too late to be considered for a given release, or we will
>> never
On Tue, Mar 17, 2015 at 01:28:21PM -0400, Tom Lane wrote:
> Or in short: yes, the rules are different for committers and non
> committers. That's one of the reasons we are slow to hand out commit
> bits.
I think one reason the rules are different for committers and
non-committers is that committe
* Bruce Momjian (br...@momjian.us) wrote:
> I think the larger issue is that we have to adjust to a new-normal where
> Tom isn't going to be as helpful in this area. Do we need more
> committers? Do we need to adjust the process or dates? These are
> probably the questions we should be addressin
Robert Haas writes:
> What I was complaining about is new feature patches for 9.5 arriving
> after the start of the last CF. There has to be some date after which
> a patch is too late to be considered for a given release, or we will
> never ship a release. We can argue about what that date is,
On Tue, Mar 17, 2015 at 12:47 PM, Bruce Momjian wrote:
> Sorry to be coming late to this thread. I don't think the problem is
> that Tom is working on these patches. Rather, I think since Tom's
> employer now cares more about his current work, Tom just isn't as
> available to help with commitfes
On Tue, Mar 17, 2015 at 01:03:03PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think one valid criticism is that Tom should transition his
> > commitments to this new-normal, especially for the the Grouping Set
> > patch, rather than allowing things to dangle in an unknown state.
>
> We
Bruce Momjian writes:
> I think one valid criticism is that Tom should transition his
> commitments to this new-normal, especially for the the Grouping Set
> patch, rather than allowing things to dangle in an unknown state.
Well, as far as that goes, I had every intention of getting to the
GROUP
On Mon, Mar 9, 2015 at 03:06:24PM -0400, Robert Haas wrote:
> On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane wrote:
> > As far as that goes, it has never been the case that we expected every
> > patch to go through the commitfest review process. (If we did, our
> > response time to bugs would be proba
2015-03-11 0:24 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > On the technical side, I do agree that the requirement to allocate and
> > zero an array for every new simple expression is unfortunate, but I'm
> > not convinced that repeatedly invoking the hook-function is a good way
> > to solve t
On Mon, Mar 09, 2015 at 03:06:24PM -0400, Robert Haas wrote:
> What I do care about
> is that we as a project have to at some point be willing to begin
> closing the spigot on new patches and focusing on polishing and
> shipping the patches we've already got. I think it's perfectly
> reasonable to
Robert Haas writes:
> On the technical side, I do agree that the requirement to allocate and
> zero an array for every new simple expression is unfortunate, but I'm
> not convinced that repeatedly invoking the hook-function is a good way
> to solve that problem. Calling the hook-function figures
On Mon, Mar 9, 2015 at 4:03 PM, Andres Freund wrote:
> FWIW, I think you actually don't have much reason to complain. This work
> has probably gotten more attention in total than any other recent
> patch. Certainly, by far, more than any other in the 9.5 cycle.
That has to be true, because the pa
On 2015-03-09 13:15:59 -0700, Peter Geoghegan wrote:
> I must say that I share your concern here. I have no idea what's going
> to happen with my ON CONFLICT patch, 9.5-wise. I hope that at least
> the IGNORE variant makes it into 9.5, but I'm not sure that it will.
>
> The ON CONFLICT IGNORE/UPDA
On Mon, Mar 9, 2015 at 12:06 PM, Robert Haas wrote:
> Yes, I understand. I don't really have anything more to say about
> this. Nothing here changes my basic feeling that we need to stop
> putting new irons in the fire and start working hard on taking irons
> out of the fire; and I think most if
On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane wrote:
> As far as that goes, it has never been the case that we expected every
> patch to go through the commitfest review process. (If we did, our
> response time to bugs would be probably a couple orders of magnitude
> longer than it is.) The way I see
Robert Haas writes:
> On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane wrote:
>> JD sees the situation correctly: this is $dayjob work, and it's going
>> to get done now not in four months because I have a deadline to meet.
>> I would like to push it into the community sources to reduce divergence
>> be
I don't think Tom, or that matter anyone needs to forgo working on changes
at any time. The only effect missing a commitfest deadline means is that
other reviewers don't offer any promises to give any feedback on it before
this round of the commitfest is done.
We don't have a policy of requiring
On Mon, Mar 9, 2015 at 1:03 PM, Andres Freund wrote:
> On 2015-03-09 12:54:44 -0400, Robert Haas wrote:
>> If we're changing that policy for patches submitted by Salesforce
>> employes, I'm afraid I must object unless EnterpriseDB employees will
>> get the same privilege. And I think 2ndQuadrant
On 2015-03-09 12:54:44 -0400, Robert Haas wrote:
> If we're changing that policy for patches submitted by Salesforce
> employes, I'm afraid I must object unless EnterpriseDB employees will
> get the same privilege. And I think 2ndQuadrant will want in on it,
> too.
Right. I'm not really sure how
On Mon, Mar 9, 2015 at 12:53 PM, Joshua D. Drake wrote:
> I think it is ridiculous to post on the bad/good/timing of a patch
> submission unless there is a case being made that the process isn't actually
> being followed. I don't see that here.
The CommitFest deadline was three weeks ago and I th
* Andres Freund (and...@2ndquadrant.com) wrote:
> > JD sees the situation correctly: this is $dayjob work, and it's going
> > to get done now not in four months because I have a deadline to meet.
> > I would like to push it into the community sources to reduce divergence
> > between our copy and Sa
On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On 03/09/2015 09:11 AM, Robert Haas wrote:
>>> I object on the grounds that we're three weeks past the deadline for
>>> the last CommitFest, and that we should be trying to get committed
>>> those patches that were su
On 03/09/2015 09:29 AM, Robert Haas wrote:
On Mon, Mar 9, 2015 at 12:26 PM, Joshua D. Drake wrote:
From the reading the original post it seems like the patch was developed on
Sales Force's time, not TGLs. I do not think we get to have an opinion on
that.
Salesforce gets to develop their pa
> JD sees the situation correctly: this is $dayjob work, and it's going
> to get done now not in four months because I have a deadline to meet.
> I would like to push it into the community sources to reduce divergence
> between our copy and Salesforce's, but if I'm told it has to wait till
> 9.6,
"Joshua D. Drake" writes:
> On 03/09/2015 09:11 AM, Robert Haas wrote:
>> I object on the grounds that we're three weeks past the deadline for
>> the last CommitFest, and that we should be trying to get committed
>> those patches that were submitted on time, not writing new ones that
>> will furth
On Mon, Mar 9, 2015 at 12:26 PM, Joshua D. Drake wrote:
> From the reading the original post it seems like the patch was developed on
> Sales Force's time, not TGLs. I do not think we get to have an opinion on
> that.
Salesforce gets to develop their patches whenever they want, but they
don't get
On 03/09/2015 09:11 AM, Robert Haas wrote:
On Sun, Mar 8, 2015 at 11:37 PM, Tom Lane wrote:
Objections? Even better ideas?
I object on the grounds that we're three weeks past the deadline for
the last CommitFest, and that we should be trying to get committed
those patches that were submitt
On Sun, Mar 8, 2015 at 11:37 PM, Tom Lane wrote:
> Objections? Even better ideas?
I object on the grounds that we're three weeks past the deadline for
the last CommitFest, and that we should be trying to get committed
those patches that were submitted on time, not writing new ones that
will furt
We already knew that plpgsql's setup_param_list() is a bit of a
performance hog. Trying to improve that was the primary motivation
behind commit f4e031c662a6b600b786c4849968a099c58fcce7 (the
bms_next_member business), though that was just micro-optimization
rather than any fundamental rethink of h
41 matches
Mail list logo
