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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
