|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andreas Karlsson <andreas(at)proxel(dot)se>|
|Cc:||Mitar <mmitar(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Feature: temporary materialized views|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> On 1/17/19 4:57 PM, Tom Lane wrote:
>> What is the stumbling block to just leaving that alone?
> I think the issue Mitar ran into is that the temporary materialized view
> is created in the rStartup callback of the receiver which happens after
> SECURITY_RESTRICTED_OPERATION is set in ExecCreateTableAs(), so the
> creation of the view itself is denied.
> From a cursory glance it looks like it would be possible to move the
> setting of SECURITY_RESTRICTED_OPERATION to inside the rStartup
> callabck, other than that the code for resetting the security context
> might get a bit ugly. Do you see any flaws with that solution?
Don't think that works: the point here is to restrict what can happen
during planning/execution of the view query, so letting planning and
query startup happen first is no good.
Creating the view object inside the rStartup callback is itself pretty
much of a kluge; you'd expect that to happen earlier. I think the
reason it was done that way was it was easier to find out the view's
column set there, but I'm sure we can find another way --- doing the
object creation more like a regular view does it is the obvious approach.
regards, tom lane
|Next Message||Bruce Momjian||2019-01-17 19:48:51||Re: Protect syscache from bloating with negative cache entries|
|Previous Message||Chris Travers||2019-01-17 18:30:24||Re: Proposal for Signal Detection Refactoring|