Re: Rethinking the parameter access hooks for plpgsql's benefit

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 Salesforce's, but if I'm told it has to wait till
>> 9.6, I may or may not remember to try to do something then.

> Sure, I have things that I've wanted to push into the community
> sources for the benefit of EnterpriseDB, too. Nobody's offered to let
> me ignore the community process when it happens to be good for
> EnterpriseDB. 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.

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 the policy is that committers have
authority to commit things that they feel are ready and that haven't
been objected to by other developers. Depending on the particular
committer and the particular patch, feeling that a patch is "ready"
might or might not require that it's been through a commitfest review.
There is no process-based restriction on committing "ready" patches
except when we are in alpha/beta/RC states, which is surely months
away for 9.5.

If I were looking for a formal review on this one, I would certainly
not expect that it would get one during the current CF. I wasn't
though.

For context, I have currently got half a dozen irons in the fire:

* "expanded objects" (array performance fixes): needs review, was
submitted timely to current CF

* operator precedence changes: committable IMO, but it's not entirely
clear if we have consensus

* adjust loop count estimates for semijoins: committable IMO, waiting
for objections

* find stats on-the-fly for children of UNION ALL appendrels: WIP, far
from done though

* flatten empty sub-SELECTs and VALUES where feasible: committable IMO,
waiting for objections

* parameter fetch hook rethink: WIP, not as close to done
as I thought last night

I wasn't really planning to use the CF process for any but the first
of these. If we start insisting that committers go through CF for
even rather small patches like these other things, it's going to
destroy our productivity completely.

regards, tom lane