Hello, At Fri, 9 Oct 2015 18:40:32 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote in <56178b90.4030...@lab.ntt.co.jp> > > What do you think the right behavior?
# 'is' was omitted.. > IIUC, I think that the foreign scan's slot should be set empty, that Even for the case, EvalPlanQualFetchRowMarks retrieves tuples of remote tables out of the whole-row resjunks and set them to es_epqTuple[] so that EvalPlanQualNext can use it. The behavior is not different from the 'FOR UPDATE;' (for all tables) cases. I supposed that whole-row value for the joined tuple would be treated in the same manner to the case of the tuples of base foreign relations. This is because preprocess_rowmarks makes rowMarks of the type LCS_NONE for the relations other than the designated by "OF colref" for "FOR UPDATE". Then it is converted into ROW_MARK_COPY by select_rowmark_type, which causes the behavior above, as the default behavior for foreign tables. > the join should fail, and that the updated version of the tuple in v > should be ignored in that scenario since that for the updated version > of the tuple in v, the tuples obtained from those two foreign tables > wouldn't satisfy the remote query. AFAICS, no updated version for remote tables are obtained. Even though the behavior I described above is correct, the join would fail, too. But it is because v.r is no longer equal to bigft2.r in the whole-row-var tuples. This seems seemingly the same behavior with that on local tables. # LCS_NONE for local tables is converted into ROW_MARK_COPY if no # securityQuals are attached. > But if populating the foreign > scan's slot from that column, then the join would success and the > updated version of the tuple in v would be returned wrongly, I think. I might understand wrongly in some points.. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
