Que tal Federico. Al final no tuve tiempo de probarlo desde libertya, pero no entiendo bien lo que me estas queriendo decir, en particular el tema de que no resuelve las referencias. Yo lo que probe fue, desde pgAdmin, crear un función que creaba una tabla y un vista y luego la ejecute; esta ejecución creó la tabla y la vista lo más bien.
En tiempo de creación de una función postgres debe hacer algún tipo de parsing, pero no hace chequeo de referencias; la siguiente función se crea lo más bien
CREATE OR REPLACE FUNCTION fEjFunction2 () RETURNS CHARACTER VARYING AS $$
BEGIN
set search_path to libertya;
create table ejTabla2(
id integer not null,
name character varying(40)
);
— insert en la tabla creada justo antes
insert into ejTabla2(id,name) values (10,’nombre’);
create view ejView2 as select * from ad_client;
RETURN ”;
END;
$$ LANGUAGE ‘plpgsql’;
Fijate que el insert hace referencia a una tabla inexistente en tiempo de creación de la función (tiempo de parsing). La ejecución de esa función (select * from fEjFunction2 (); ) crea la tabla y agrega la fila normalmente.
Incluso creando un función que haga referencia a una tabla no va a existir tiempo de ejecución no tira problemas de parsing.Ej
CREATE OR REPLACE FUNCTION fEjFunction3 () RETURNS CHARACTER VARYING AS $$
BEGIN
— insert en la tabla creada justo antes
insert into ejTablaINEXISTENTE(id,name) values (10,’nombre’);
RETURN ”;
END;
$$ LANGUAGE ‘plpgsql’;
La creación de la función no tira errror; obviamente si lo hará la ejecución (ERROR: relation “ejtablainexistente” does not exist)
En cualquier caso yo proponía esta forma solo para ejecutar el preinstall.sql o como un método general para aquellos casos en el que sería bueno ejecutar múltiples sentencias; todo lo demás lo veo correcto que sea haga via los xmls en el caso de los componentes (no creo que tenga tanta importancia la performance en este caso; nadie instala componentes todo el tiempo).
