AWS redshift documentation change
Summary
Added section explaining automatic query rewrite behavior and permissions implications
Security assessment
Documents access control implications of materialized view usage but does not fix a security issue. Highlights permission requirements for underlying tables.
Diff
diff --git a/redshift/latest/dg/materialized-view-auto-rewrite.md b/redshift/latest/dg/materialized-view-auto-rewrite.md index d78eca815..68979e067 100644 --- a//redshift/latest/dg/materialized-view-auto-rewrite.md +++ b//redshift/latest/dg/materialized-view-auto-rewrite.md @@ -5 +5 @@ -Usage notesLimitations +Usage notesHow automatic query rewriting of materialized views worksLimitations @@ -46,0 +47,8 @@ You can stop automatic query rewriting at the session level by using SET mv_enab +## How automatic query rewriting of materialized views works + +Based on internal optimization, Amazon Redshift may decide to invoke automatic query rewriting of materialized views transparently to provide the most optimal query execution with the lowest possible query times. + +For example, suppose User A creates a materialized view M1 on table T1 with the query `SELECT * FROM T1`. User A has full SELECT privileges on T1. User A grants access to M1 to all users, including User B. However, when User B tries to query T1 directly, they are denied access. This is because User B does not have SELECT privileges on T1. + +Sometime later, User B again tries to query T1, but this time gets results back from T1. This is because automatic query rewrite using materialized view rewrote User B's query on table T1 (`SELECT _< cols>_ FROM T1`) to a query on materialized view M1 (`SELECT _< cols>_ FROM M1`). +