aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/json.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2015-03-12 13:38:49 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2015-03-12 13:38:49 -0400
commit5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603 (patch)
treec8c11ebb5b5486778d65a708b4d108322ef77a21 /src/backend/utils/adt/json.c
parentd16d821faa5a2c97e2fb532daa9a032b48129c91 (diff)
downloadpostgresql-5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603.tar.gz
postgresql-5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603.zip
Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples.
The ROW_MARK_COPY path in EvalPlanQualFetchRowMarks() was just setting tableoid to InvalidOid, I think on the assumption that the referenced RTE must be a subquery or other case without a meaningful OID. However, foreign tables also use this code path, and they do have meaningful table OIDs; so failure to set the tuple field can lead to user-visible misbehavior. Fix that by fetching the appropriate OID from the range table. There's still an issue about whether CTID can ever have a meaningful value in this case; at least with postgres_fdw foreign tables, it does. But that is a different problem that seems to require a significantly different patch --- it's debatable whether postgres_fdw really wants to use this code path at all. Simplified version of a patch by Etsuro Fujita, who also noted the problem to begin with. The issue can be demonstrated in all versions having FDWs, so back-patch to 9.1.
Diffstat (limited to 'src/backend/utils/adt/json.c')
0 files changed, 0 insertions, 0 deletions