On Thu, Nov 19, 2020 at 8:47 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 2020-11-17 02:32, Michael Paquier wrote:
> >> The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
> >> executed without further Access Rule checking", which means the INSERT
> >> privilege shouldn't be required at all. I suggest we consider doing that
> >> instead. I don't see a use for the current behavior.
> > Hmm. Is there anything specific for materialized views? They've
> > checked for INSERT privileges at this phase since their introduction
> > in 3bf3ab8c.
>
> Materialized views are not in the SQL standard.
>
> But if you consider materialized views as a variant of normal views,
> then the INSERT privilege would be applicable if you pass an INSERT on
> the materialized view through to the underlying tables, like for a view.
>
> Also note that REFRESH on a materialized view does not check any
> privileges (only ownership), so having a privilege that only applies
> when the materialized view is created doesn't make sense.
>
So, should we be doing it this way?
For CTAS: retain the existing CREATE privilege check and remove the
INSERT privilege check altogether for all the cases i.e. with data,
with no data, explain analyze, plain, with execute?
For CREATE MATERIALIZED VIEW: same as CTAS, that is retain the
existing CREATE privilege check and remove the INSERT privilege check
for with data, with no data, explain analyze, plain?
For REFRESH MATERIALIZED VIEW: retain the existing behaviour i.e. no
privilege check.
If okay, I can make a patch.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
