On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>

> On 2016/03/19 4:51, Robert Haas wrote:
>> On Thu, Mar 17, 2016 at 7:00 AM, Etsuro Fujita
>> <fujita.ets...@lab.ntt.co.jp> wrote:
>>> So, I'd like to propose: (1) when tableoids are
>>> requested from the remote server, postgres_fdw sets valid values for
>>> them locally, instead (core should support that?)
> Sure.
> and (2) when any of
>>> xmins, xmaxs, cmins, and cmaxs are requested, postgres_fdw gives up
>>> pushing down foreign joins.  (We might be able to set appropriate values
>>> for them locally the same way as for tableoids, but I'm not sure it's
>>> worth complicating the code.)  I think that would be probably OK,
>>> because users wouldn't retrieve any such columns in practice.
> Now that seems like the wrong reaction.  I mean, aren't these just
>> going to be 0 or something?  Refusing to push the join down seems
>> strange.
> OK, I'll modify the patch so that the join is pushed down even if any of
> xmins, xmaxs, cmins, and cmaxs are requested.  Do you think which one
> should set values for these as well as tableoids, postgres_fdw or core?

Earlier in this mail chain, I suggested that the core should take care of
storing the values for these columns. But instead, I think, core should
provide functions which can be used by FDWs, if they want, to return values
for those columns. Something like Datum
get_syscol_value(RelOptInfo/Relation, attno). The function will return
Datum 0 for most of the columns and table's OID for tableoid. My 0.02.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Reply via email to