Inserir, em atualização duplicada no PostgreSQL?

Vários meses atrás, aprendi com uma resposta no Stack Overflow como executar várias atualizações de uma vez no MySQL usando a seguinte sintaxe:

INSERT INTO table (id, field, field2) VALUES (1, A, X), (2, B, Y), (3, C, Z)
ON DUPLICATE KEY UPDATE field=VALUES(Col1), field2=VALUES(Col2);

Agora mudei para o PostgreSQL e, aparentemente, isso não está correto. Está se referindo a todas as tabelas corretas, portanto, presumo que sejam usadas palavras-chave diferentes, mas não tenho certeza de onde isso está coberto na documentação do PostgreSQL.

Para esclarecer, quero inserir várias coisas e, se elas já existirem, atualizá-las.

O PostgreSQL desde a versão 9.5 possui sintaxe UPSERT , com a cláusula ON CONFLICT . com a seguinte sintaxe (semelhante ao MySQL)

INSERT INTO the_table (id, column_1, column_2) 
VALUES (1, 'A', 'X'), (2, 'B', 'Y'), (3, 'C', 'Z')
ON CONFLICT (id) DO UPDATE 
  SET column_1 = excluded.column_1, 
      column_2 = excluded.column_2;

A busca por "upsert" nos arquivos do grupo de e-mail do postgresql leva a encontrar um exemplo de como você possivelmente quer fazer, no manual :

Exemplo 38-2 Exceções com UPDATE / INSERT

Este exemplo usa manipulação de exceção para executar UPDATE ou INSERT, conforme apropriado:

CREATE TABLE db (a INT PRIMARY KEY, b TEXT);

CREATE FUNCTION merge_db(key INT, data TEXT) RETURNS VOID AS
$$
BEGIN
    LOOP
        -- first try to update the key
        -- note that "a" must be unique
        UPDATE db SET b = data WHERE a = key;
        IF found THEN
            RETURN;
        END IF;
        -- not there, so try to insert the key
        -- if someone else inserts the same key concurrently,
        -- we could get a unique-key failure
        BEGIN
            INSERT INTO db(a,b) VALUES (key, data);
            RETURN;
        EXCEPTION WHEN unique_violation THEN
            -- do nothing, and loop to try the UPDATE again
        END;
    END LOOP;
END;
$$
LANGUAGE plpgsql;

SELECT merge_db(1, 'david');
SELECT merge_db(1, 'dennis');

Existe possivelmente um exemplo de como fazer isso em massa, usando CTEs na 9.1 e acima, na lista de e-mails dos hackers :

WITH foos AS (SELECT (UNNEST(%foo[])).*)
updated as (UPDATE foo SET foo.a = foos.a ... RETURNING foo.id)
INSERT INTO foo SELECT foos.* FROM foos LEFT JOIN updated USING(id)
WHERE updated.id IS NULL;

Veja a resposta de a_horse_with_no_name para um exemplo mais claro.

Aviso: isso não é seguro se executado a partir de várias sessões ao mesmo tempo (veja advertências abaixo).

Outra maneira inteligente de executar um "UPSERT" no postgresql é executar duas instruções UPDATE / INSERT sequenciais, cada uma projetada para ter sucesso ou não ter efeito.

UPDATE table SET field='C', field2='Z' WHERE id=3;
INSERT INTO table (id, field, field2)
       SELECT 3, 'C', 'Z'
       WHERE NOT EXISTS (SELECT 1 FROM table WHERE id=3);

O UPDATE será bem-sucedido se uma linha com "id = 3" já existir, caso contrário não terá efeito.

O INSERT terá êxito apenas se a linha com "id = 3" ainda não existir.

Você pode combinar esses dois em uma única sequência e executá-los com uma única instrução SQL executada no seu aplicativo. Executá-los juntos em uma única transação é altamente recomendado.

Isso funciona muito bem quando executado isoladamente ou em uma tabela bloqueada, mas está sujeito a condições de corrida, o que significa que ainda poderá falhar com erro de chave duplicada se uma linha for inserida simultaneamente ou pode terminar sem nenhuma linha inserida quando uma linha for excluída simultaneamente. . Uma SERIALIZABLEtransação no PostgreSQL 9.1 ou superior irá lidar com isso de maneira confiável ao custo de uma taxa de falha de serialização muito alta, o que significa que você precisará tentar muito. Vejo por que o upsert é tão complicado , que discute esse caso com mais detalhes.

Esta abordagem também é sujeito a atualizações perdidas em read committedisolamento, a menos que a aplicação verifica a contagem de linhas afetadas e verifica que tanto o insertou o updateafetou uma linha .

Com o PostgreSQL 9.1, isso pode ser alcançado usando um CTE gravável ( expressão de tabela comum ):

WITH new_values (id, field1, field2) as (
  values 
     (1, 'A', 'X'),
     (2, 'B', 'Y'),
     (3, 'C', 'Z')

),
upsert as
( 
    update mytable m 
        set field1 = nv.field1,
            field2 = nv.field2
    FROM new_values nv
    WHERE m.id = nv.id
    RETURNING m.*
)
INSERT INTO mytable (id, field1, field2)
SELECT id, field1, field2
FROM new_values
WHERE NOT EXISTS (SELECT 1 
                  FROM upsert up 
                  WHERE up.id = new_values.id)

Veja estas entradas do blog:

• Upserting via CTE gravável
• ESPERANDO 9.1 - CTE ESCRITA
• POR QUE A UPSERT É TÃO COMPLICADA?

Observe que esta solução não evita uma violação exclusiva da chave, mas não é vulnerável a atualizações perdidas.
Veja o acompanhamento de Craig Ringer em dba.stackexchange.com

No PostgreSQL 9.5 e mais recente, você pode usar INSERT ... ON CONFLICT UPDATE.

Veja a documentação .

Um MySQL INSERT ... ON DUPLICATE KEY UPDATEpode ser reformulado diretamente para a ON CONFLICT UPDATE. A sintaxe padrão do SQL também não é, ambas são extensões específicas do banco de dados. Existem boas razões para MERGEnão ter sido usado para isso , uma nova sintaxe não foi criada apenas por diversão. (A sintaxe do MySQL também tem problemas que significam que não foi adotado diretamente).

por exemplo, dada configuração:

CREATE TABLE tablename (a integer primary key, b integer, c integer);
INSERT INTO tablename (a, b, c) values (1, 2, 3);

a consulta do MySQL:

INSERT INTO tablename (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

torna-se:

INSERT INTO tablename (a, b, c) values (1, 2, 10)
ON CONFLICT (a) DO UPDATE SET c = tablename.c + 1;

Diferenças:

• Você deve especificar o nome da coluna (ou nome exclusivo da restrição) a ser usado para a verificação de exclusividade. Essa é aON CONFLICT (columnname) DO

• A palavra-chave SETdeve ser usada, como se fosse uma UPDATEdeclaração normal

Também possui alguns recursos interessantes:

• Você pode ter uma WHEREcláusula UPDATE(permitindo efetivamente transformar-se ON CONFLICT UPDATEem ON CONFLICT IGNOREcertos valores)

• Os valores propostos para inserção estão disponíveis como a variável de linha EXCLUDED, que possui a mesma estrutura da tabela de destino. Você pode obter os valores originais na tabela usando o nome da tabela. Então, neste caso EXCLUDED.c, será 10(porque foi o que tentamos inserir) e "table".cserá 3porque esse é o valor atual na tabela. Você pode usar uma ou ambas as SETexpressões e WHEREcláusula.

Para obter mais informações sobre o upsert, consulte Como UPSERT (MERGE, INSERT ... ON DUPLICATE UPDATE) no PostgreSQL?

Eu estava procurando a mesma coisa quando cheguei aqui, mas a falta de uma função genérica "upsert" me incomodou um pouco, então pensei que você poderia simplesmente passar a atualização e inserir sql como argumentos nessa função do manual

que ficaria assim:

CREATE FUNCTION upsert (sql_update TEXT, sql_insert TEXT)
    RETURNS VOID
    LANGUAGE plpgsql
AS $$
BEGIN
    LOOP
        -- first try to update
        EXECUTE sql_update;
        -- check if the row is found
        IF FOUND THEN
            RETURN;
        END IF;
        -- not found so insert the row
        BEGIN
            EXECUTE sql_insert;
            RETURN;
            EXCEPTION WHEN unique_violation THEN
                -- do nothing and loop
        END;
    END LOOP;
END;
$$;

e, talvez, para fazer o que você inicialmente queria, em lotes "upsert", você poderia usar o Tcl para dividir o sql_update e fazer o loop das atualizações individuais, o resultado da pré-execução será muito pequeno, consulte http://archives.postgresql.org/pgsql- performance / 2006-04 / msg00557.php

o custo mais alto é a execução da consulta a partir do seu código, no lado do banco de dados o custo de execução é muito menor

Não há um comando simples para fazê-lo.

A abordagem mais correta é usar a função, como a dos documentos .

Outra solução (embora não tão segura) é atualizar com o retorno, verificar quais linhas foram atualizadas e inserir o restante delas.

Algo ao longo das linhas de:

update table
set column = x.column
from (values (1,'aa'),(2,'bb'),(3,'cc')) as x (id, column)
where table.id = x.id
returning id;

assumindo id: 2 foi retornado:

insert into table (id, column) values (1, 'aa'), (3, 'cc');

É claro que ele será resgatado mais cedo ou mais tarde (em ambiente concorrente), pois há uma clara condição de corrida aqui, mas geralmente funcionará.

Aqui está um artigo mais longo e abrangente sobre o assunto .

Pessoalmente, configurei uma "regra" anexada à instrução insert. Digamos que você tenha uma tabela "dns" que registre hits de DNS por cliente em uma base de tempo:

CREATE TABLE dns (
    "time" timestamp without time zone NOT NULL,
    customer_id integer NOT NULL,
    hits integer
);

Você queria poder reinserir linhas com valores atualizados ou criá-las se elas já não existissem. Introduziu o customer_id e a hora. Algo assim:

CREATE RULE replace_dns AS 
    ON INSERT TO dns 
    WHERE (EXISTS (SELECT 1 FROM dns WHERE ((dns."time" = new."time") 
            AND (dns.customer_id = new.customer_id)))) 
    DO INSTEAD UPDATE dns 
        SET hits = new.hits 
        WHERE ((dns."time" = new."time") AND (dns.customer_id = new.customer_id));

Atualização: isso pode falhar se inserções simultâneas estiverem acontecendo, pois gerará exceções de violação única. No entanto, a transação não finalizada continuará e terá êxito, e você só precisará repetir a transação finalizada.

No entanto, se houver muitas inserções acontecendo o tempo todo, você desejará colocar um bloqueio de tabela em torno das instruções de inserção: O bloqueio SHARE ROW EXCLUSIVE impedirá qualquer operação que possa inserir, excluir ou atualizar linhas na tabela de destino. No entanto, as atualizações que não atualizam a chave exclusiva são seguras; portanto, se nenhuma operação fizer isso, use bloqueios de aviso.

Além disso, o comando COPY não usa REGRAS, portanto, se você estiver inserindo com COPY, precisará usar gatilhos.

Eu uso essa função mesclar

CREATE OR REPLACE FUNCTION merge_tabla(key INT, data TEXT)
  RETURNS void AS
$BODY$
BEGIN
    IF EXISTS(SELECT a FROM tabla WHERE a = key)
        THEN
            UPDATE tabla SET b = data WHERE a = key;
        RETURN;
    ELSE
        INSERT INTO tabla(a,b) VALUES (key, data);
        RETURN;
    END IF;
END;
$BODY$
LANGUAGE plpgsql

Customizei a função "upsert" acima, se você deseja INSERIR E SUBSTITUIR:

`

 CREATE OR REPLACE FUNCTION upsert(sql_insert text, sql_update text)

 RETURNS void AS
 $BODY$
 BEGIN
    -- first try to insert and after to update. Note : insert has pk and update not...

    EXECUTE sql_insert;
    RETURN;
    EXCEPTION WHEN unique_violation THEN
    EXECUTE sql_update; 
    IF FOUND THEN 
        RETURN; 
    END IF;
 END;
 $BODY$
 LANGUAGE plpgsql VOLATILE
 COST 100;
 ALTER FUNCTION upsert(text, text)
 OWNER TO postgres;`

E depois de executar, faça algo como isto:

SELECT upsert($$INSERT INTO ...$$,$$UPDATE... $$)

É importante colocar uma vírgula dupla para evitar erros do compilador

• verifique a velocidade ...

Semelhante à resposta mais curtida, mas funciona um pouco mais rápido:

WITH upsert AS (UPDATE spider_count SET tally=1 WHERE date='today' RETURNING *)
INSERT INTO spider_count (spider, tally) SELECT 'Googlebot', 1 WHERE NOT EXISTS (SELECT * FROM upsert)

(fonte: http://www.the-art-of-web.com/sql/upsert/ )

Tenho o mesmo problema para gerenciar as configurações da conta que os pares de valor e nome. O critério de design é que clientes diferentes possam ter conjuntos de configurações diferentes.

Minha solução, semelhante ao JWP, é apagar e substituir em massa, gerando o registro de mesclagem no seu aplicativo.

Isso é bastante à prova de balas, independente de plataforma e, como nunca há mais de 20 configurações por cliente, são apenas três chamadas db de carga bastante baixa - provavelmente o método mais rápido.

A alternativa de atualizar linhas individuais - verificar se há exceções e depois inserir - ou alguma combinação de código hediondo, é lento e frequentemente quebra porque (como mencionado acima) o tratamento de exceção SQL fora do padrão, alterando de db para db - ou mesmo de liberação para liberação.

 #This is pseudo-code - within the application:
 BEGIN TRANSACTION - get transaction lock
 SELECT all current name value pairs where id = $id into a hash record
 create a merge record from the current and update record
  (set intersection where shared keys in new win, and empty values in new are deleted).
 DELETE all name value pairs where id = $id
 COPY/INSERT merged records 
 END TRANSACTION

De acordo com a documentação da INSERTdeclaração do PostgreSQL , o tratamento do ON DUPLICATE KEYcaso não é suportado. Essa parte da sintaxe é uma extensão proprietária do MySQL.

CREATE OR REPLACE FUNCTION save_user(_id integer, _name character varying)
  RETURNS boolean AS
$BODY$
BEGIN
    UPDATE users SET name = _name WHERE id = _id;
    IF FOUND THEN
        RETURN true;
    END IF;
    BEGIN
        INSERT INTO users (id, name) VALUES (_id, _name);
    EXCEPTION WHEN OTHERS THEN
            UPDATE users SET name = _name WHERE id = _id;
        END;
    RETURN TRUE;
END;

$BODY$
  LANGUAGE plpgsql VOLATILE STRICT

Para mesclar conjuntos pequenos, usar a função acima é adequado. No entanto, se você estiver mesclando grandes quantidades de dados, sugiro consultar http://mbk.projects.postgresql.org

A melhor prática atual que eu conheço é:

1. COPIE os dados novos / atualizados na tabela temporária (com certeza, ou você pode fazer INSERT se o custo estiver bom)
2. Adquirir bloqueio [opcional] (o aconselhamento é preferível aos bloqueios de tabela, IMO)
3. Mesclar. (a parte divertida)

UPDATE retornará o número de linhas modificadas. Se você usar JDBC (Java), poderá verificar esse valor em relação a 0 e, se nenhuma linha tiver sido afetada, acionar INSERT. Se você usar alguma outra linguagem de programação, talvez o número de linhas modificadas ainda possa ser obtido, consulte a documentação.

Isso pode não ser tão elegante, mas você tem um SQL muito mais simples que é mais trivial para usar no código de chamada. Diferentemente, se você escrever o script de dez linhas no PL / PSQL, provavelmente deverá ter um teste de unidade de um ou outro tipo apenas para ele.

Editar: Isso não funciona conforme o esperado. Diferentemente da resposta aceita, isso gera violações de chave exclusivas quando dois processos chamam repetidamenteupsert_foo simultaneamente.

Eureka! Eu descobri uma maneira de fazer isso em uma consulta: use UPDATE ... RETURNINGpara testar se alguma linha foi afetada:

CREATE TABLE foo (k INT PRIMARY KEY, v TEXT);

CREATE FUNCTION update_foo(k INT, v TEXT)
RETURNS SETOF INT AS $$
    UPDATE foo SET v = $2 WHERE k = $1 RETURNING $1
$$ LANGUAGE sql;

CREATE FUNCTION upsert_foo(k INT, v TEXT)
RETURNS VOID AS $$
    INSERT INTO foo
        SELECT $1, $2
        WHERE NOT EXISTS (SELECT update_foo($1, $2))
$$ LANGUAGE sql;

O UPDATEque deve ser feito em um procedimento separado, porque, infelizmente, este é um erro de sintaxe:

... WHERE NOT EXISTS (UPDATE ...)

Agora funciona como desejado:

SELECT upsert_foo(1, 'hi');
SELECT upsert_foo(1, 'bye');
SELECT upsert_foo(3, 'hi');
SELECT upsert_foo(3, 'bye');