Re: WIP patch (v2) for updatable security barrier views
От | Tom Lane |
---|---|
Тема | Re: WIP patch (v2) for updatable security barrier views |
Дата | |
Msg-id | 18451.1390977809@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP patch (v2) for updatable security barrier views (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: WIP patch (v2) for updatable security barrier views
Re: WIP patch (v2) for updatable security barrier views Re: WIP patch (v2) for updatable security barrier views |
Список | pgsql-hackers |
Kouhei Kaigai <kaigai@ak.jp.nec.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
В списке pgsql-hackers по дате отправления: