Inserisci, su aggiornamento duplicato in PostgreSQL?

Diversi mesi fa ho imparato da una risposta su Stack Overflow come eseguire più aggiornamenti contemporaneamente in MySQL usando la sintassi seguente:

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);

Ora sono passato a PostgreSQL e apparentemente questo non è corretto. Si riferisce a tutte le tabelle corrette, quindi presumo sia una questione di parole chiave diverse utilizzate ma non sono sicuro di dove sia coperto nella documentazione di PostgreSQL.

Per chiarire, voglio inserire diverse cose e se esistono già per aggiornarle.

PostgreSQL dalla versione 9.5 ha la sintassi UPSERT , con la clausola ON CONFLICT . con la seguente sintassi (simile a 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;

Cercare "upert" negli archivi del gruppo di posta elettronica di postgresql porta a trovare un esempio di come si può fare ciò che si desidera fare, nel manuale :

Esempio 38-2. Eccezioni con UPDATE / INSERT

In questo esempio viene utilizzata la gestione delle eccezioni per eseguire UPDATE o INSERT, come appropriato:

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');

C'è forse un esempio di come eseguire questa operazione in blocco, utilizzando CTE in 9.1 e versioni successive, nella mailing list degli hacker :

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;

Vedi la risposta di a_horse_with_no_name per un esempio più chiaro.

Attenzione: questo non è sicuro se eseguito da più sessioni contemporaneamente (vedere avvertenze di seguito).

Un altro modo intelligente di fare un "UPSERT" in postgresql è fare due istruzioni UPDATE / INSERT sequenziali progettate ciascuna per avere successo o senza effetti.

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);

L'AGGIORNAMENTO avrà esito positivo se esiste già una riga con "id = 3", altrimenti non ha alcun effetto.

L'INSERIMENTO avrà esito positivo solo se la riga con "id = 3" non esiste già.

È possibile combinare questi due in un'unica stringa ed eseguirli entrambi con un'unica istruzione SQL eseguita dall'applicazione. Si consiglia vivamente di eseguirli insieme in un'unica transazione.

Funziona molto bene se eseguito in modo isolato o su una tabella bloccata, ma è soggetto a condizioni di competizione che indicano che potrebbe comunque non riuscire con un errore di chiave duplicata se una riga viene inserita contemporaneamente o potrebbe terminare senza una riga inserita quando una riga viene eliminata contemporaneamente . Una SERIALIZABLEtransazione su PostgreSQL 9.1 o versioni successive la gestirà in modo affidabile al costo di un tasso di fallimento della serializzazione molto elevato, il che significa che dovrai riprovare molto. Scopri perché upsert è così complicato , che discute questo caso in modo più dettagliato.

Questo approccio è anche soggetto a aggiornamenti persi in read committedisolamento a meno che l'applicazione non controlli il conteggio delle righe interessate e verifichi che la riga interessata inserto quella updateinteressata .

Con PostgreSQL 9.1 questo può essere ottenuto usando un CTE scrivibile ( espressione di tabella comune ):

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)

Vedi questi post di blog:

• Upserting via CTE scrivibile
• ASPETTANDO 9.1 - CTE SCRITTABILE
• PERCHÉ UPSERT È COSÌ COMPLICATO?

Questa soluzione non impedisce una violazione chiave univoca ma non è vulnerabile agli aggiornamenti persi.
Guarda il seguito di Craig Ringer su dba.stackexchange.com

In PostgreSQL 9.5 e versioni successive è possibile utilizzare INSERT ... ON CONFLICT UPDATE.

Vedere la documentazione .

Un MySQL INSERT ... ON DUPLICATE KEY UPDATEpuò essere riformulato direttamente in a ON CONFLICT UPDATE. Né è sintassi standard SQL, sono entrambe estensioni specifiche del database. Ci sono buoni motivi per cui MERGEnon è stato usato per questo , una nuova sintassi non è stata creata solo per divertimento. (La sintassi di MySQL ha anche problemi che indicano che non è stata adottata direttamente).

ad es. impostazione data:

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

la query MySQL:

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

diventa:

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

differenze:

• È necessario specificare il nome della colonna (o il nome univoco del vincolo) da utilizzare per il controllo di unicità. Quello è ilON CONFLICT (columnname) DO

• La parola chiave SETdeve essere utilizzata, come se fosse UPDATEun'istruzione normale

Ha anche alcune belle funzionalità:

• Puoi avere una WHEREclausola sul tuo UPDATE(permettendoti di trasformarti efficacemente ON CONFLICT UPDATEin ON CONFLICT IGNOREdeterminati valori)

• I valori proposti per l'inserimento sono disponibili come variabile di riga EXCLUDED, che ha la stessa struttura della tabella di destinazione. È possibile ottenere i valori originali nella tabella utilizzando il nome della tabella. Quindi in questo caso EXCLUDED.csarà 10(perché è quello che abbiamo cercato di inserire) e "table".csarà 3perché questo è il valore corrente nella tabella. È possibile utilizzare uno o entrambi nelle SETespressioni e nella WHEREclausola.

Per informazioni su upsert vedi Come UPSERT (MERGE, INSERT ... ON DUPLICATE UPDATE) in PostgreSQL?

Stavo cercando la stessa cosa quando sono venuto qui, ma la mancanza di una generica funzione "upsert" mi ha disturbato un po ', quindi ho pensato che potresti semplicemente passare l'aggiornamento e inserire sql come argomenti su quella funzione dal manuale

sarebbe simile a questo:

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 forse per fare ciò che inizialmente volevi fare, batch "upsert", potresti usare Tcl per dividere sql_update e eseguire il loop dei singoli aggiornamenti, il colpo di preformance sarà molto piccolo vedi http://archives.postgresql.org/pgsql- prestazioni / 2006-04 / msg00557.php

il costo più alto è l'esecuzione della query dal tuo codice, dal lato del database il costo di esecuzione è molto più piccolo

Non esiste un comando semplice per farlo.

L'approccio più corretto è usare la funzione, come quella di documenti .

Un'altra soluzione (anche se non così sicura) è fare l'aggiornamento con la restituzione, controllare quali righe erano aggiornamenti e inserirne il resto

Qualcosa sulla falsariga di:

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;

assumendo id: 2 è stato restituito:

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

Ovviamente prima o poi verrà salvato (in un ambiente concorrente), in quanto vi sono chiare condizioni di gara qui, ma di solito funzionerà.

Ecco un articolo più lungo e completo sull'argomento .

Personalmente, ho impostato una "regola" allegata all'istruzione insert. Supponiamo che tu abbia una tabella "dns" che registra gli hit DNS per cliente su una base temporale:

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

Volevi poter reinserire le righe con valori aggiornati o crearle se non esistevano già. Digitato su customer_id e l'ora. Qualcosa come questo:

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));

Aggiornamento: questo ha il potenziale per fallire se si verificano inserimenti simultanei, in quanto genererà eccezioni unique_violation. Tuttavia, la transazione non terminata continuerà e avrà esito positivo e sarà sufficiente ripetere la transazione terminata.

Tuttavia, se ci sono tonnellate di inserti che accadono continuamente, vorrai mettere un blocco della tabella attorno alle istruzioni di inserimento: il blocco SHARE ROW EXCLUSIVE impedirà qualsiasi operazione che possa inserire, eliminare o aggiornare le righe nella tabella di destinazione. Tuttavia, gli aggiornamenti che non aggiornano la chiave univoca sono sicuri, quindi se non si esegue alcuna operazione, utilizzare invece i blocchi di avviso.

Inoltre, il comando COPIA non utilizza le REGOLE, quindi se si inserisce con COPIA, è necessario utilizzare invece i trigger.

Uso questa funzione di unione

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

Ho personalizzato la funzione "upsert" sopra, se vuoi INSERIRE E SOSTITUIRE:

`

 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 dopo l'esecuzione, fai qualcosa del genere:

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

È importante inserire la doppia virgola per evitare errori del compilatore

• controlla la velocità ...

Simile alla risposta più apprezzata, ma funziona leggermente più velocemente:

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/ )

Ho lo stesso problema per la gestione delle impostazioni dell'account delle coppie valore-nome. Il criterio di progettazione prevede che client diversi possano avere impostazioni di impostazioni diverse.

La mia soluzione, simile a JWP, consiste nel cancellare e sostituire in blocco, generando il record di unione all'interno dell'applicazione.

Questo è piuttosto antiproiettile, indipendente dalla piattaforma e poiché non ci sono mai più di circa 20 impostazioni per client, si tratta solo di 3 chiamate db a carico abbastanza basso - probabilmente il metodo più veloce.

L'alternativa all'aggiornamento di singole righe - verifica delle eccezioni e poi dell'inserimento - o una combinazione di è il codice orribile, lento e spesso si interrompe perché (come menzionato sopra) la gestione delle eccezioni SQL non standard che cambia da db a db - o addirittura rilasciare per rilasciare.

 #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

Secondo la documentazione PostgreSQL INSERTdell'istruzione , la gestione del ON DUPLICATE KEYcaso non è supportata. Quella parte della sintassi è un'estensione proprietaria di 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

Per unire piccoli set, usare la funzione sopra va bene. Tuttavia, se si stanno unendo grandi quantità di dati, suggerirei di consultare http://mbk.projects.postgresql.org

L'attuale best practice di cui sono a conoscenza è:

1. COPIA i dati nuovi / aggiornati nella tabella temporanea (certo, oppure puoi INSERIRE se il costo è ok)
2. Acquisisci blocco [opzionale] (è preferibile un avviso ai blocchi tabella, IMO)
3. Unisci. (la parte divertente)

UPDATE restituirà il numero di righe modificate. Se si utilizza JDBC (Java), è possibile quindi verificare questo valore su 0 e, se non sono state interessate righe, attivare invece INSERT. Se si utilizza un altro linguaggio di programmazione, forse è ancora possibile ottenere il numero delle righe modificate, consultare la documentazione.

Potrebbe non essere così elegante, ma hai SQL molto più semplice che è più banale da usare dal codice chiamante. Diversamente, se scrivi lo script a dieci righe in PL / PSQL, probabilmente dovresti avere un test unitario di uno o un altro tipo solo per esso.

Modifica: non funziona come previsto. A differenza della risposta accettata, questo produce violazioni chiave uniche quando due processi chiamano ripetutamente upsert_foocontemporaneamente.

Eureka! Ho trovato un modo per farlo in una sola query: utilizzare UPDATE ... RETURNINGper verificare se sono state interessate righe:

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;

La UPDATEdeve essere fatto in una procedura separata, perché, purtroppo, questo è un errore di sintassi:

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

Ora funziona come desiderato:

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