Re: ExplainModifyTarget doesn't work as expected

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ExplainModifyTarget doesn't work as expected
Date: 2015-02-10 05:49:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2015/02/07 1:09, Tom Lane wrote:
> IIRC, this code was written at a time when we didn't have NO INHERIT check
> constraints and so it was impossible for the parent table to get optimized
> away while leaving children. So the comment in ExplainModifyTarget was
> good at the time. But it no longer is.
> I think your basic idea of preserving the original parent table's relid
> is correct; but instead of doing it like this patch does, I'd be inclined
> to make ModifyTable inherit from Scan not Plan, and use the scan.scanrelid
> field to carry the parent RTI. Then you would probably end up with a net
> savings of code rather than net addition; certainly ExplainModifyTarget
> would go away entirely since you'd just treat ModifyTable like any other
> Scan in this part of EXPLAIN.

Will follow your revision.


Best regards,
Etsuro Fujita

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-02-10 06:19:04 Re: Odd behavior of updatable security barrier views on foreign tables
Previous Message Atri Sharma 2015-02-10 02:35:02 Re: GSoC 2015 - mentors, students and admins.