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
