Re: Custom Scan APIs (Re: Custom Plan node)

Kouhei Kaigai <kaigai@ak.jp.nec.com>

From: Kouhei Kaigai <kaigai@ak.jp.nec.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, PgHacker <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Stephen Frost <sfrost@snowman.net>, Shigeru Hanada <shigeru.hanada@gmail.com>, Jim Mlodgenski <jimmy76@gmail.com>, "Peter Eisentraut" <peter_e@gmx.net>
Date: 2014-04-16T04:11:11Z
Lists: pgsql-hackers
> Andres Freund <andres@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".
> 
Yep, today is the expected feature freeze date towards v9.4.
It is little bit late to include v9.4 features, unfortunately.

> 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.
>
Hmm. If we have something like expression_tree_walker/mutator for plan nodes,
we can pass a walker/mutator function's pointer instead of exposing static
functions that takes recursive jobs.
If custom-plan provider (that has sub-plans) got a callback with walker/
mutator pointer, all it has to do for sub-plans are calling this new
plan-tree walking support routine with supplied walker/mutator.
It seems to me more simple design than what I did.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.