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
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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to