Hello.
At Tue, 26 Jun 2018 10:19:45 +0530, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote in
<CAFjFpRdZeiOwW+Ahj2xKACdmtirC8HzwLFNgGn4=dSsLpP8ADw@mail.gmail.com>
> On Tue, Jun 26, 2018 at 9:59 AM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@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
