Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Thom Brown <thom(at)linux(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date: 2015-05-11 02:25:48
Message-ID: 20150511022548.GL12950@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
> On Sun, May 10, 2015 at 8:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-05-11 02:37:19 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Previous Message Robert Haas 2015-05-11 01:53:45 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)