Andreas Karlsson <andr...@proxel.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.
Hm.
> 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
