On 16-09-2016 13:30, [email protected] wrote:
> 2016-09-16 11:04 GMT-03:00 <[email protected]>:
>>
>> Então Alex, o detalhe é que vão existir muitos erros (indefinidos) que
>> vou
>> tratar com o tempo e durante esse tempo tenho que manter os OK
>
>> Pressuponho que já tenhas estudado 40.6.6. Trapping Errors em
>> https://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html
>>
>
>
> Então Dutra, como ja percebeu eu não sou DBA, rsrs, minha rotina não é
> em PL dentro do banco
>
Você viu o link acima? Ele explica que você pode pegar qualquer erro e
tratar numa exceção (é claro que isso tem um custo). Vide o exemplo abaixo:
DROP TABLE IF EXISTS foo;
DROP TABLE IF EXISTS bar;
DROP FUNCTION IF EXISTS foobar();
CREATE TABLE foo (a int, b int);
CREATE TABLE bar (a int, b int, check(a % 2 = 0));
CREATE FUNCTION foobar() RETURNS void AS $$
DECLARE
r record;
BEGIN
FOR r IN SELECT a, b FROM foo LOOP
BEGIN
INSERT INTO bar (a, b) VALUES(r.a, r.b);
EXCEPTION WHEN OTHERS THEN
RAISE NOTICE 'INSERT falhou (%, %)', r.a, r.b;
END;
END LOOP;
END;
$$
LANGUAGE plpgsql;
INSERT INTO foo (a, b) SELECT i, i + 3 FROM generate_series(1, 5000) i;
SELECT foobar();
A cada tentativa de inserir um valor ímpar da tabela foo na tabela bar
haverá uma falhar da restrição CHECK. A função foobar trata essa exceção
não fazendo nada (apenas imprime a mensagem de falha). E assim, ele vai
inserindo na tabela bar somente valores da coluna 'a' que são números pares.
> Uma pergunta, sem antes ter testado, rsrs, será que um PREPARE SQL antes
> de cada Insert ou Update me traria o erro antes de efetivar?
>
Não. PREPARE tem haver com separar as fases de execução de um único comando.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
