On 4/6/17 8:13 PM, Tom Lane wrote:
>> It's on the pointy end for Pg10, and I thought we'd be fine to include
>> this in pg10 then aim to clean up DestReceiver in early pg11, or even
>> as a post-feature-freeze refactoring fixup in pg10. Should the
>> callback approach be blocked because the API it has to use is a bit
>> ugly?
> Given Peter's objections, I don't think this is getting into v10 anyway,
> so we might as well take a bit more time and do it right.
Well, Peter's objection is that we're not going far enough in plpython,
but there's absolutely no way to do more without breaking plpy, which
seems a non-starter. We should certainly be able to expand the existing
API to provide even more benefit, but I see no reason to leave the
performance gain this patch provides on the floor just because there's
more to be had with a different API.
> Also, I'm entirely -1 on "post-feature-freeze refactoring fixups".
> We're going to have more than enough to do trying to stabilize the
> existing committed code, I fear (cf Robert's pessimistic summary of
> the open-items list, a couple days ago). We don't need to be
> planning on doing new design post-freeze, whether it's painted as
> mere refactoring or not.
Agreed, and I agree that the current patch is a bit of a hack when it
comes to DestReceiver (or really, DestReceiver has become an ugly wart
over the years, as you pointed out).
I'll plan to pick this up again once the dust settles on this commitfest.
--
Jim Nasby, Chief Data Architect, Austin TX
OpenSCG http://OpenSCG.com
