On Wed, Apr 13, 2016 at 5:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
