Hi,
On 2016-03-10 15:03:41 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Primarily because create_plan(), and/or its children, have to know about
> > what you're doing; you can hide some, but not all, things below
> > CustomScan nodes.
>
> And which of those things does e.g. setrefs.c not need to know about?
For CustomScans? You can mostly get by with ->custom_exprs.
> > ISTM, that there's good enough reasons to go either way; I don't see
> > what we're gaining by making these private. That just encourages
> > copy-paste coding.
>
> What it encourages is having module boundaries that actually mean
> something, as well as code that can be refactored without having
> to worry about which extensions will complain about it.
I personally think it's entirely fine to break extensions if it's adding
or removing a few parameters or somesuch. That's easy enough fixed.
> I will yield on this point because it's not worth my time to argue about
> it, but I continue to say that it's a bad decision you will regret.
FWIW, I do agree that it'd be much nicer to use the new API; the biggest
user in Citus should be able to work with that. But it's not that easy
to do that and still support postgres 9.4/9.5.
> Which functions did you need exactly? I'm not exporting more than
> I have to.
I'll try to do the port tomorrow; to make sure I have the definitive
list. Afaics it's just make_seqscan, make_sort_from_sortclauses,
make_limit, make_agg. I'd not however be surprised if other extensions
also use some of these.
Would you rather add back the exports or should I?
Greetings,
Andres