Andres Freund <and...@2ndquadrant.com> writes:
> What I think this discussion shows that this patch isn't ready for
> 9.4. The first iteration of the patch came in 2013-11-06. Imo that's
> pretty damn late for a relatively complex patch. And obviously we don't
> have agreement on the course forward.
> I don't think we need to stop discussing, but I think it's pretty clear
> that this isn't 9.4 material. And that it's far from "Ready for Committer".
Yeah. I'm still not exactly convinced that custom-scan will ever allow
independent development of new plan types (which, with all due respect to
Robert, is what it was being sold as last year in Ottawa). But I'm not
opposed in principle to committing it, if we can find a way to have a
cleaner API for things like setrefs.c. It seems like late-stage planner
processing in general is an issue for this patch (createplan.c and
subselect.c are also looking messy). EXPLAIN isn't too great either.
I'm not sure exactly what to do about those cases, but I wonder
whether things would get better if we had the equivalent of
expression_tree_walker/mutator capability for plan nodes. The state
of affairs in setrefs and subselect, at least, is a bit reminiscent
of the bad old days when we had lots of different bespoke code for
traversing expression trees.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
