(2014/06/30 17:47), Ashutosh Bapat wrote:
I checked that it's reporting the right tableoid now.
Thank you for the check.
BTW, why aren't you using the tlist passed to this function? I guess
create_scan_plan() passes tlist after processing it, so that should be
used rather than rel->reltargetlist.
I think that that would be maybe OK, but I think that it would not be
efficient to use the list to compute attrs_used, because the tlist would
have more information than rel->reltargetlist in cases where the tlist
is build through build_physical_tlist().
On Mon, Jun 30, 2014 at 12:22 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/06/24 16:30), Etsuro Fujita wrote:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Selecting tableoid on parent causes an error, "ERROR:
system attribute from virtual tuple". The foreign table has
an OID which
can be reported as tableoid for the rows coming from that
Do we want to do that?
No. I think it's a bug. I'll fix it.
Done. I think this is because create_foreignscan_plan() makes
reference to attr_needed, which isn't computed for inheritance
children. To aboid this, I've modified create_foreignscan_plan() to
see reltargetlist and baserestrictinfo, instead of attr_needed.
Please find attached an updated version of the patch.
Sorry for the delay.
The Postgres Database Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: