Esneiker Enriquez Cabrera escribió:
> Esta es una función que dejó de funcionar.
>
> CREATE OR REPLACE FUNCTION actualizar_archivo_adjunto()
> RETURNS trigger AS
> $BODY$
> BEGIN
> UPDATE mensaje SET archivo_adjunto=1 WHERE mensaje.id=new.id_mensaje;
> UPDATE expediente_incidencia SET archivo_adjunto=1, leido=FALSE WHERE
> expediente_incidencia.id=new.id_expdte_inc;
> RETURN NEW;
> END;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE
> COST 100;
> ALTER FUNCTION actualizar_archivo_adjunto() OWNER TO postgres;
>
> No hacía el update luego de crear los nuevos esquemas. El search_path no lo
> he tocado.
¿tendrás tablas mensaje o expediente_incidencia en los nuevos esquemas?
De ser así, es muy posible que la función esté tratando de modificar las
nuevas tablas en lugar de las que están en public -- suponiendo que el
search_path tenga los otros esquemas antes que public.
La solución es poner los nombres de objetos de manera que no sean
ambiguos. Por ej. podrías hacer esto
UPDATE public.mensaje SET archivo_adjunto=1 WHERE
mensaje.id=new.id_mensaje;
o bien podrías poner una cláusula SET en el CREATE FUNCTION, por ej.
CREATE OR REPLACE FUNCTION public.actualizar_archivo_adjunto() RETURNS trigger
SET search_path TO 'public'
AS $body$
begin
update ...
$body$;
(Esto hace que el search_path se modifique a valor especificado cada vez
que se ejecute la función).
De hecho hacerlo de esta forma es importante, porque te protejes de que
algún payaso cree objetos antes que los tuyos en search_path y te haga
ejecutar código definido por él que tú no querrías. (En otras palabras
hay una vulnerabilidad de seguridad en la forma como lo estás haciendo
actualmente).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
