Re: WIP patch (v2) for updatable security barrier views

On 29 January 2014 06:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
>> Let me ask an elemental question. What is the reason why inheritance
>> expansion logic should be located on the planner stage, not on the tail
>> of rewriter?
>
> I think it's mostly historical. You would however have to think of a
> way to preserve the inheritance relationships in the parsetree
> representation. In the current code, expand_inherited_tables() adds
> AppendRelInfo nodes to the planner's data structures as it does the
> expansion; but I don't think AppendRelInfo is a suitable structure
> for the rewriter to work with, and in any case there's no place to
> put it in the Query representation.
>
> Actually though, isn't this issue mostly about inheritance of a query
> *target* table? Moving that expansion to the rewriter is a totally
> different and perhaps more tractable change. It's certainly horribly ugly
> as it is; hard to see how doing it at the rewriter could be worse.
>

That's interesting. Presumably then we could make rules work properly
on inheritance children. I'm not sure if anyone has actually
complained that that currently doesn't work.

Thinking about that though, it does potentially open up a whole other
can of worms --- a single update query could be turned into multiple
other queries of different command types. Perhaps that's not so
different from what currently happens in the rewriter, except that
you'd need a way to track which of those queries counts towards the
statement's final row count. And how many ModifyTable nodes would the
resulting plan have?

Regards,
Dean