Re: Odd system-column handling in postgres_fdw join pushdown patch

On Wed, Apr 13, 2016 at 5:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 2. When a join is pushed down, deparse system columns using something
>> like "CASE WHEN r1.* IS NOT NULL THEN 0 END", except for the table OID
>> column, which gets deparsed with the table OID in place of 0. This
>> delivers the correct behavior in the presence of outer joins.
>
> Um, why would that be necessary? Surely the correct things will happen
> on the far end without that, if it's implementing the same join semantics
> as the local query would have.

I don't know exactly what you mean by "without that". Currently, the
situation is:

1. When postgres_fdw scans a baserel, the xmin, xmax, and cmin/cmax
fields reflect the reinterpreted contents of the datumtuple header
fields. Blech.

2. When postgres_fdw scans a joinrel (the join is pushed down), any
references to xmin/xmax/cmin/cmax reflect the values of those fields
on the remote sides.

#1 is obviously stupid, although maybe not that stupid since nobody
cared enough to fix it before now. #2 is arguably correct, but I
figure it's not a good idea to display the remote values of those
fields on the local system - local transaction IDs and remote
transaction IDs exist in two different XID spaces, and I think
shouldn't be conflated. So what I'm proposing to do is standardize on
this:

When postgres_fdw scans a baserel *or* a joinrel, any references to
xmin/xmax/cmin/cmax are read as 0.

There are alternatives. We could decide that the joinrel case (which,
BTW, is what the OP complained about) is right and the baserel case is
wrong, and change the baserel case to work like the joinrel case. I'm
not enamored of that, but it's not totally nuts. The one thing I'm
sure about is that the current baserel behavior is stupid.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company