No es inusual querer tener un solo script para implementar un cambio. La cuestión es que dicho script debe ser ejecutado por un usuario avanzado, ya que debe tener privilegios del sistema en CUALQUIER nivel. Esto generalmente significa una cuenta de DBA, preferiblemente una cuenta de aplicación, pero de lo contrario SYSTEM o SYS.
Entonces, el script que desea se vería así:
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
/
Un escenario común es que tenemos un conjunto de scripts individuales que han sido escritos para que los ejecuten diferentes usuarios, pero que ahora necesitamos agrupar en una sola implementación. Los scripts originales no contienen los nombres de esquema, y hay muchas buenas razones por las que no querríamos codificarlos en los scripts.
Una forma de construir ese script maestro es cambiar la sintaxis 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
Todavía necesitamos un usuario DBA para ejecutar el script maestro. Una ventaja de cambiar el esquema actual es que nos permite implementar objetos como enlaces de bases de datos, que por una peculiaridad de la sintaxis no pueden tener el nombre del esquema en su declaración. Un problema es que el usuario no cambia, por lo que un script que emplea la pseudocolumna USER puede producir resultados no deseados.
