Re: [HACKERS] postgres_fdw bug in 9.6
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] postgres_fdw bug in 9.6 |
Дата | |
Msg-id | CAFjFpRe44DBHYn3MccVVbV-rF2XMNGjm3Nn734cXDS+aiM2LPg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres_fdw bug in 9.6 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Sat, Apr 8, 2017 at 12:03 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Apr 3, 2017 at 2:12 AM, Etsuro Fujita > <fujita.etsuro@lab.ntt.co.jp> wrote: >> On 2017/04/01 1:32, Jeff Janes wrote: >>> On Thu, Mar 23, 2017 at 5:20 AM, Etsuro Fujita >>> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> wrote: >>> Done. Attached is a new version of the patch. >>> Is the fix for 9.6.3 going to be just a back port of this, or will it >>> look different? >> >> +1 for backporting; although that requires that GetForeignJoinPaths be >> updated so that the FDW uses a new function to create an alternative local >> join path (ie, CreateLocalJoinPath), that would make maintenance of the code >> easy. > > Well, the problem here is that this breaks ABI compatibility. If we > applied this to 9.6, and somebody tried to use a previously-compiled > FDW .so against a new server version, it would fail after the upgrade, > because the new server wouldn't have GetExistingLocalJoinPath and also > possibly because of the change to the structure of JoinPathExtraData. > Maybe there's no better alternative, and maybe nothing outside of > postgres_fdw is using this stuff anyway, but it seems like a concern. I had submitted a patch in [1]. We thought that that patch is good to fix the issue on the backbranches. But it got berried in the thread. If you think that's a feasible solution for backbranches, I will work on the comments. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: