Hi, On 2016-03-10 15:03:41 -0500, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
