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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP patch (v2) for updatable security barrier views
Date: 2014-01-29 06:43:29
Message-ID: 18451.1390977809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-29 06:51:15 Re: Add min and max execute statement time in pg_stat_statement
Previous Message Tom Lane 2014-01-29 05:53:02 Re: updated emacs configuration