On Tue, Aug 29, 2017 at 5:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: >> [ epqpath-for-foreignjoin-11.patch ] > > I started looking at this. I've not yet wrapped my head around what > CreateLocalJoinPath() is doing, but I noted that Robert's concerns > about ABI breakage in the back branches would not be very difficult > to satisfy. What we'd need to do is > > (1) In the back-branch patch, add the new fields of JoinPathExtraData > at the end, rather than in their more natural locations. This should > avoid any ABI break for uses of that struct, since there's no reason > why an FDW would be creating its own variables of that type rather > than just using what the core code passes it. > > (2) In the back branches, just leave GetExistingLocalJoinPath in place > rather than deleting it. Existing FDWs would still be subject to the > bug until they were updated, but given how hard it is to trigger, that > doesn't seem like a huge problem. > > A variant of (2) is to install a hack fix in GetExistingLocalJoinPath > rather than leaving it unchanged. I'm not very excited about that though; > it doesn't seem unlikely that we might introduce new bugs that way, and > it would certainly be a distraction from getting the real fix finished. > > We'd definitely need to do things that way in 9.6. I'm not quite sure > whether it's too late to adopt the clean solution in v10.
It probably is now. Are you still planning to do something about this patch? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
