No es inusual querer tener un solo script para implementar un cambio. El hecho es que una secuencia de comandos debe ser ejecutada por un usuario avanzado, ya que necesita tener privilegios del sistema en el nivel ANY. Esto generalmente significa una cuenta de DBA, preferiblemente una cuenta de aplicación, pero de lo contrario SYSTEM o SYS.
Así que 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 secuencias de comandos individuales que se han escrito para ser ejecutado por diferentes usuarios, pero que ahora tenemos que agrupar en una sola implementación. Las secuencias de comandos originales no contienen los nombres de los esquemas, y hay muchas buenas razones por las que no deseamos codificarlas en las secuencias de comandos.
Una forma de construir esa secuencia de comandos principal es utilizar la sintaxis cambiar 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 principal. Una ventaja de cambiar el esquema actual es que nos permite implementar objetos como enlaces de bases de datos, que a través de una peculiaridad de sintaxis no pueden tener el nombre del esquema en su declaración. Una sorpresa es que el usuario no cambia, por lo que una secuencia de comandos que emplea la pseudocolumna del USUARIO puede producir resultados no deseados.
No tiene sentido: las secuencias de comandos no existen en un esquema, son solo una lista de comandos que el usuario que está conectando a la instancia tiene el privilegio de ejecutar. Las declaraciones de concesión IIRC son por objeto (IE: tabla). Por favor, reformule su pregunta para que quede más claro de lo que está preguntando. –