Hello. At Tue, 26 Jun 2018 10:19:45 +0530, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote in <CAFjFpRdZeiOwW+Ahj2xKACdmtirC8HzwLFNgGn4=dsslpp8...@mail.gmail.com> > On Tue, Jun 26, 2018 at 9:59 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > >> But good thing is because of join and aggregate > >> push-down we already have ability to push arbitrary kinds of nodes > >> down to the foreign server through the targetlist. We should be able > >> to leverage that capability. It looks like a lot of change, which > >> again doesn't seem to be back-portable. > > > > After some struggles as you know, I agree to the opinion. As my > > first impression, giving (physical) base relations (*1) an > > ability to have junk attribute is rather straightforward. > > By giving base relations an ability to have junk attribute you mean to > add junk attribute in the targetlist of DML, something like > postgresAddForeignUpdateTargets(). You seem to be fine with the new
Maybe. > node approach described above. Just confirm. Something-like-but-other-hanVar node? I'm not sure it is needed, because whatever node we add to the relation-tlist, we must add the correspondence to the relation descriptor. And if we do that, a Var works to point it. (Am I correctly understanding?) > > > > Well, is our conclusion here like this? > > > > - For existing versions, check the errorneous situation and ERROR out. > > (documentaion will be needed.) > > > > - For 12, we try the above thing. > > I think we have to see how invasive the fix is, and whether it's > back-portable. If it's back-portable, we back-port it and the problem > is fixed in previous versions as well. If not, we fix previous > versions to ERROR out instead of corrupting the database. Mmm. Ok, I try to make a patch. Please wait for a while. regards. -- Kyotaro Horiguchi NTT Open Source Software Center