> On 2015-05-10 21:26:26 -0400, Robert Haas wrote: > > On Sun, May 10, 2015 at 8:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > This commit reverts create_plan_recurse() as static function. > > > Yes. I am not convinced that external callers should be calling that, > > > and would prefer not to enlarge createplan.c's API footprint without a > > > demonstration that this is right and useful. (This is one of many > > > ways in which this patch is suffering from having gotten committed > > > without submitted use-cases.) > > Wasn't there a submitted use case? IIRC Kaigai had referenced some > pg-strom (?) code using it? > > I'm failing to see how create_plan_recurse() being exposed externally is > related to "having gotten committed without submitted use-cases". Even > if submitted, presumably as simple as possible code, doesn't use it, > that's not a proof that less simple code does not need it. > Yes, PG-Strom code uses create_plan_recurse() to construct child plan node of the GPU accelerated custom-join logic, once it got chosen. Here is nothing special. It calls create_plan_recurse() as built-in join path doing on the underlying inner/outer paths. It is not difficult to submit as a working example, however, its total code size (excludes GPU code) is 25KL at this moment.
I'm not certain whether it is a simple example. > > Your unwillingness to make functions global or to stick PGDLLIMPORT > > markings on variables that people want access to is hugely > > handicapping extension authors. Many people have complained about > > that on multiple occasions. Frankly, I find it obstructionist and > > petty. > > While I don't find the tone of the characterization super helpful, I do > tend to agree that we're *far* too conservative on that end. I've now > seen a significant number of extension that copied large swathes of code > just to cope with individual functions not being available. And even > cases where that lead to minor forks with such details changed. > I may have to join the members? > I know that I'm "fearful" of asking for functions being made > public. Because it'll invariably get into a discussion of merits that's > completely out of proportion with the size of the change. And if I, who > has been on the list for a while now, am "afraid" in that way, you can > be sure that others won't even dare to ask, lest argue their way > through. > > I think the problem is that during development the default often is to > create function as static if they're used only in one file. Which is > fine. But it really doesn't work if it's a larger battle to change > single incidences. Besides the pain of having to wait for the next > major release... > Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
