Não é incomum querer ter um único script para implantar uma mudança. O problema é que esse script precisa ser executado por um usuário avançado, porque precisa ter privilégios de sistema em QUALQUER nível. Isso geralmente significa uma conta DBA, de preferência uma conta de aplicativo, mas de outra forma SYSTEM ou SYS.
Então o script que você quer ficaria assim:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
Um cenário comum é que temos um conjunto de scripts individuais que foram escritos para serem executados por diferentes usuários, mas que agora precisamos agrupar em uma única implantação. Os scripts originais não contêm os nomes dos esquemas e há muitas boas razões pelas quais não desejaríamos codificá-los nos scripts.
Uma maneira de construir esse script mestre é usar alterar a sintaxe CURRENT_SCHEMA:
alter session set current_schema=USER_A
/
@run_grants_to_userb.sql
alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql
Ainda precisamos de um usuário DBA para executar o script mestre. Uma vantagem de alternar o esquema atual é que ele nos permite implantar objetos como links de banco de dados, que por meio de uma peculiaridade de sintaxe não podem ter o nome do esquema em sua declaração. Uma pegadinha é que o usuário não muda, então um script que emprega a pseudo-coluna USER pode produzir resultados indesejados.
