// GPDB_83_MERGE_FIXME: Why do we check permissions here? The executor
// will do it anyway...
// The parsed query contains an RTE for the view, which is maintained all the way through planned statement.
// This entries is annotated as requiring SELECT permissions for the current user.
// In Orca, we only keep range table entries for the base tables in the planned statement, but not for the view itself.
// Since permissions are only checked during ExecutorStart, we lose track of the permissions required for the view and the select goes through successfully.
// We therefore need to check permissions before we go into optimization for all RTEs, including the ones not explicitly referred in the query, e.g. views.
-- OpenSSL SHA2 returning a different SHA2 to RSA BSAFE!
--select rolname, rolpassword from pg_authid where rolname = 'sha256';
drop role sha256;
drop view if exists t1_view;
NOTICE: view "t1_view" does not exist, skipping
drop table if exists t1;
NOTICE: table "t1" does not exist, skipping
drop role if exists u1;
drop role if exists superuser;
create role superuser;
NOTICE: resource queue required -- using default resource queue "pg_default"
create role u1;
NOTICE: resource queue required -- using default resource queue "pg_default"
set role superuser;
create table t1(a int, b int constraint c check (b>=100));
NOTICE: Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'a' as the Greenplum Database data distribution key for this table.
HINT: The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
create view t1_view as select * from t1;
grant all privileges on t1, t1_view to u1;
set role superuser;
revoke all privileges on TABLE t1, t1_view FROM u1;
