Sim, não está bem assim?
CREATE TRIGGER trg_postfire_study_area_UPDATE_dimensoes
BEFORE INSERT OR UPDATE
ON sch_forestal.postfire_study_area
FOR EACH ROW
EXECUTE PROCEDURE fun_dimensoes();
Eloi Ribeiro
GIS Analyst
39,45º -0,40º
flavors.me/eloiribeiro
No dia 20 de Março de 2012 15:09, Matheus de Oliveira <
[email protected]> escreveu:
> A trigger é BEFORE? Caso contrário não atualiza mesmo.
>
>
>
> --
> Matheus de Oliveira
>
> Bacharelado em Ciências de Computação
> Laboratório de Computação de Alto Desempenho -
> LCAD<http://www.lcad.icmc.usp.br/>
> Instituto de Ciências Matemáticas e de Computação -
> ICMC<http://www.icmc.usp.br/>
> Universidade de São Paulo - USP <http://www.sc.usp.br/>
>
>
>
>
> On Tue, Mar 20, 2012 at 10:57 AM, Eloi Ribeiro <[email protected]>wrote:
>
>> Obrigado a todos pelas vossas dicas.
>>
>> Fiz isso, retirei a parte de criação de colunas da função e agora não
>> salta nenhum erro.
>> No entanto seria de esperar que quando um polígono fosse editado o campo
>> área fosse actualizado e isso não acontece.
>>
>> Alguém me sabe dizer o que é que está mal?
>>
>>
>>
>> CREATE OR REPLACE FUNCTION fun_dimensoes()
>> RETURNS trigger AS
>> $BODY$
>> DECLARE
>> tipo varchar(20);
>> srid integer;
>> BEGIN
>> tipo := (SELECT "type" FROM geometry_columns
>> WHERE f_table_schema = TG_TABLE_SCHEMA
>> AND f_table_name = TG_TABLE_NAME);
>> srid := (SELECT srid FROM geometry_columns
>> WHERE f_table_schema = TG_TABLE_SCHEMA
>> AND f_table_name = TG_TABLE_NAME);
>> -- ponto
>> IF (tipo = 'POINT' OR tipo = 'MULTIPOINT') THEN
>> NEW.x = ST_X(NEW.geom);
>> NEW.y = ST_Y(NEW.geom);
>> -- linha
>> ELSIF (tipo = 'LINESTRING' OR tipo = 'MULTILINESTRING') THEN
>>
>> IF (srid = 23030 OR srid = 25830) THEN
>> NEW.longitude = ST_Length(NEW.geom)::bigint;
>>
>> ELSIF (srid = 4326) THEN
>> NEW.longitude = ST_Length(Geography(NEW.geom))::bigint;
>> END IF;
>> -- poligono
>> ELSIF (tipo = 'POLYGON' OR tipo = 'MULTIPOLYGON') THEN
>>
>> IF (srid = 23030 OR srid = 25830) THEN
>> NEW.area = ST_Area(NEW.geom)::bigint;
>> NEW.perimetro = ST_Perimeter(NEW.geom)::bigint;
>>
>> ELSIF (srid = 4326) THEN
>> NEW.area = ST_Area(Geography(NEW.geom))::bigint;
>> NEW.perimetro = ST_Length(Geography(NEW.geom))::bigint;
>> END IF;
>> END IF;
>>
>> RETURN NEW;
>> END;
>> $BODY$
>> LANGUAGE 'plpgsql' VOLATILE
>> COST 100;
>>
>> Obrigado,
>>
>>
>> Eloi Ribeiro
>> GIS Analyst
>> 39,45º -0,40º
>> flavors.me/eloiribeiro
>>
>>
>> No dia 17 de Março de 2012 21:39, Matheus de Oliveira <
>> [email protected]> escreveu:
>>
>> Se você passar a trigger para AFTER ao invés de BEFORE suas chances de
>>> não ter lock "aumentam", mas não "desaparecem". Analisando por cima suas
>>> necessidades, não acredito que a melhor solução seja realmente adicionar
>>> uma coluna em uma trigger, isso me parece uma tarefa administrativa, ou
>>> seja, sempre adicione a coluna (talvez junto com a execução do comando
>>> CREATE TRIGGER) e na trigger simplesmente considere que ela já existe (pode
>>> até fazer a verificação e dar um RAISE EXCEPTION caso não exista).
>>>
>>> PS: Caso a trigger seja genérica para várias tabelas, você pode pensar
>>> em usar herança nessas tabelas para organizar melhor as coisas.
>>>
>>> Atenciosamente,
>>> --
>>> Matheus de Oliveira
>>>
>>> Bacharelado em Ciências de Computação
>>> Laboratório de Computação de Alto Desempenho -
>>> LCAD<http://www.lcad.icmc.usp.br/>
>>> Instituto de Ciências Matemáticas e de Computação -
>>> ICMC<http://www.icmc.usp.br/>
>>> Universidade de São Paulo - USP <http://www.sc.usp.br/>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 16, 2012 at 10:07 AM, Eloi Ribeiro
>>> <[email protected]>wrote:
>>>
>>>> O melhor será separar esta função em duas:
>>>> A primeira que verifique se os campos existem e se não os criam.
>>>> E a segunda como disparador para que se actualizem com os inserts e
>>>> updates.
>>>> Obrigado pela ajuda!
>>>>
>>>>
>>>> Eloi Ribeiro
>>>> GIS Analyst
>>>> 39,45º -0,40º
>>>> flavors.me/eloiribeiro
>>>>
>>>>
>>>> No dia 16 de Março de 2012 13:04, Flavio Henrique Araque Gurgel <
>>>> [email protected]> escreveu:
>>>>
>>>> > Cancelando as demais transações/conexões também resolve seu problema
>>>>> > *se, e somente se* isto não for um problema no seu cenário.
>>>>>
>>>>> Minha experiência com DDL dentro de funções é de resultado sempre
>>>>> inesperado.
>>>>> Se a função é específica para ser executada em horário controlado,
>>>>> geralmente é uma mão na roda. DBAs de madrugada sempre se dão melhor
>>>>> executando funções do que comandos mais complexos ou scripts.
>>>>> Já se a função é para ser chamada automaticamente por causa de uma
>>>>> necessidade de uma aplicação ou usuário, a chance de lock é
>>>>> monstruosa, e é o que está ocorrendo com o colega.
>>>>>
>>>>> []s
>>>>> Flavio Gurgel
>>>>> _______________________________________________
>>>>> pgbr-geral mailing list
>>>>> [email protected]
>>>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pgbr-geral mailing list
>>>> [email protected]
>>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>>
>>>>
>>>
>>> _______________________________________________
>>> pgbr-geral mailing list
>>> [email protected]
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> [email protected]
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
