Hi ha una operació que els sistemes reals necessiten constantment i que cap de les tres instruccions anteriors no resol: "insereix aquesta fila si no existeix, i actualitza-la si ja existeix".

Sincronitzar el catàleg amb el fitxer que envia un proveïdor cada setmana: uns articles ja estan donats d'alta i només canvien de preu, altres són nous. Registrar l'estoc rebut d'una referència que potser encara no existeix. Desar la puntuació d'una ressenya que el client pot haver escrit fa mesos. Donar d'alta un client que tal vegada ja s'ha registrat. En els quatre casos, la resposta a "INSERT o UPDATE?" és depèn del que hi hagi a la taula, i no ho saps fins que ho mires.

La solució que tothom escriu la primera vegada —mirar i després decidir— és incorrecta, i ho és d'una manera que no es manifesta en desenvolupament i sí en producció. Aquesta lliçó comença explicant per què, i continua amb les dues eines que PostgreSQL ofereix per resoldre-ho en una sola sentència atòmica: INSERT ... ON CONFLICT, la seva solució pròpia des de la versió 9.5, i MERGE, la de l'estàndard SQL, disponible des de PostgreSQL 15.

1. El problema: inserir o actualitzar segons el que hi hagi
2. Per què la solució ingènua és incorrecta
3. INSERT ... ON CONFLICT: la sintaxi
4. DO NOTHING i DO UPDATE SET
5. La destinació del conflicte i per què exigeix una restricció única
6. La pseudotaula EXCLUDED i el patró d'acumulació
7. WHERE al DO UPDATE: actualitzar només si alguna cosa canvia
8. RETURNING amb upsert, i com saber si va ser alta o modificació
9. MERGE: l'upsert de l'estàndard SQL
10. ON CONFLICT davant de MERGE
11. Suport per motor
12. Tres casos de BotigaVerda
13. Errors habituals i consells
14. Exercicis
15. Conclusió

Huerta del Turia (proveïdor 1) envia cada dilluns un fitxer amb el seu catàleg actualitzat. Aquesta setmana porta cinc referències:

Quatre ja són al catàleg (amb altres preus); el cinquè és nou. I ni tan sols tots els que hi són canvien: l'arròs continua a 3,90 € i 2,10 €.

Amb el que saps fins ara, hauries de separar el fitxer a mà en dos grups i escriure un INSERT per a l'un i un UPDATE per a l'altre. És tediós, i amb cinc-centes referències és directament inviable. El que necessites és una sentència que decideixi per si sola, fila a fila.

Això és un UPSERT: update + insert.

La primera idea de qualsevol, i la que escriuen la majoria de les aplicacions:

Funciona perfectament… mentre siguis l'única persona connectada. Tan bon punt hi ha dos processos treballant alhora, apareix una condició de cursa:

Les dues sessions miren, totes dues veuen que no existeix, totes dues decideixen inserir. La primera se'n surt; la segona peta. I hi ha una variant pitjor: si no hi hagués restricció única, la segona inserció tindria èxit i acabaries amb dues files duplicades sense cap error.

L'interval entre el SELECT i l'INSERT pot semblar minúscul —mil·lisegons—, però en un sistema que processa milers d'operacions per minut aquella finestra es creua constantment. No és un cas rar: és un cas garantit. La regla general que hi ha al darrere:

Comprovar i després actuar en dues sentències separades no és mai segur davant de la concurrència. Entre la comprovació i l'acció, el món ha pogut canviar.

Les tres formes de resoldre-ho, de pitjor a millor:

Per què la tercera opció és segura. Quan PostgreSQL executa un INSERT ... ON CONFLICT, la comprovació i l'escriptura passen dins de la mateixa operació, amb el bloqueig de fila i índex adequat: no hi ha finestra entre "mirar" i "actuar". El mecanisme complet —què es bloqueja, durant quant de temps i què veuen les altres sessions— és el mòdul 9. Aquí n'hi ha prou de saber que una sentència és atòmica i dues no ho són.

Es llegeix literalment: "insereix això; si xoca amb la unicitat d'aquestes columnes, no facis res / o fes aquest UPDATE al seu lloc".

Comencem pel cas que no necessita res nou, perquè BotigaVerda ja té la restricció: clients.email és UNIQUE.

(Els tres exemples d'aquest apartat s'executen en ordre sobre la base acabada de recarregar. Fixa't en els id: el motiu que surtin els que surten s'explica al final.)

Zero files inserides, zero errors. El client ja existia amb aquell email, així que la sentència s'ha limitat a no fer res.

Intacte: continua a València i amb la seva data de registre original.

DO NOTHING és ideal per a dades mestres reexecutables: llavors de desenvolupament, catàlegs de referència, càrregues inicials. Converteix un script fràgil en un d'idempotent (05-03).

La ciutat ha passat de València a Alacant, i data_registre no ha canviat: només s'actualitza el que apareix al SET. És exactament el que volem — la data d'alta original d'un client no s'ha de reescriure perquè ens enviïn les seves dades una altra vegada.

I amb un email nou, la mateixa sentència insereix:

La mateixa sentència ha inserit en un cas i ha actualitzat en l'altre, sense que tu hagis hagut de decidir res. Això és l'upsert.

Per què l'id és 18 i no 16. BotigaVerda té 15 clients i la seva seqüència va quedar a 15 després del setval de l'script. Però un upsert que acaba en conflicte també consumeix un valor de la seqüència: PostgreSQL construeix la fila completa —avaluant tots els DEFAULT, inclòs nextval— abans de comprovar l'índex únic. Els dos exemples anteriors sobre la Lucía es van endur el 16 i el 17, i l'Aitor ha rebut el 18.

És coherent amb el que vas veure a 05-02: les seqüències no es desfan. Conseqüència pràctica: en una taula amb upserts freqüents, els id tenen buits grans i no compten files. Si això t'importa, revisa'n el tipus: un INTEGER s'esgota a 2 147 483 647, i amb upserts massius això arriba abans del que sembla. BIGINT és la resposta habitual.

L'ON CONFLICT (...) no és decoratiu: li diu a PostgreSQL quin conflicte ha d'interceptar. I només pot interceptar violacions d'una restricció UNIQUE, PRIMARY KEY o d'un índex únic.

Hi ha dues formes d'indicar-ho:

Si indiques columnes que no estan cobertes per cap restricció única, falla:

I això és una limitació de disseny, no un caprici. Perquè PostgreSQL pugui decidir atòmicament "ja existeix", necessita un índex únic que l'hi digui sense recórrer la taula; sense ell hauria de cercar, i tornaríem a la finestra de cursa de l'apartat 2.

Així que per sincronitzar el catàleg per nom cal afegir la restricció:

Funciona perquè els vint noms del catàleg són diferents. I de passada il·lustra una cosa que veuràs a fons a 05-06: afegir un UNIQUE crea un índex per sota, i aquell índex és el que fa possible l'upsert (les estructures i el seu cost, al mòdul 8).

Ara sí:

Preu i cost actualitzats; l'estoc continua a 120 perquè no és al SET. Les 60 unitats del fitxer s'han ignorat, cosa que en aquest cas és correcta: són unitats enviades, no l'estoc total.

EXCLUDED és la clau de tot el mecanisme. És una pseudotaula que conté la fila que s'ha intentat inserir i ha estat rebutjada pel conflicte.

Dins del DO UPDATE SET conviuen dos móns:

Amb tots dos pots escriure qualsevol regla de fusió:

Aquest últim és el patró d'acumulació, i és probablement l'ús més valuós de l'upsert. Registrar la recepció de mercaderia és exactament això: "si el producte ja està donat d'alta, suma-li les unitats; si no, crea'l amb aquelles unitats".

Cinc files: quatre acumulades i una creada. 120+60=180, 200+100=300, 300+200=500, 60+40=100, i els cigrons entren amb les seves 140 unitats i l'id 21.

Fixa't en un detall revelador: els preus de les quatre files actualitzades continuen sent els antics (12,50 €, 3,90 €, 1,95 €, 4,95 €), perquè el SET només toca stock. Només la fila nova ha estrenat el preu del fitxer. L'upsert et deixa controlar camp a camp què es fusiona i què es conserva.

I l'avís obligatori, germà del d'UPDATE ... FROM (05-03):

⚠️ EXCLUDED no acumula entre tuples de la mateixa sentència. Si el fitxer portés dues vegades el mateix nom, PostgreSQL fallaria amb ON CONFLICT DO UPDATE command cannot affect row a second time. No suma les dues: s'hi nega. Dedupica l'origen abans de fer upsert.

Aquell error és en realitat una bona notícia: el motor es nega a fer una cosa ambigua en lloc d'inventar-se un resultat. Compara'l amb UPDATE ... FROM, que en la mateixa situació tria una coincidència a l'atzar sense avisar.

El DO UPDATE admet el seu propi WHERE, que decideix si l'actualització s'aplica o es descarta:

Quatre files en lloc de cinc. L'arròs integral venia amb 3,90 € i 2,10 €, exactament el que ja tenia, així que el WHERE ha descartat la seva actualització i ni tan sols apareix al RETURNING.

Per què val la pena aquella línia de més:

Fixa't en l'ús d'IS DISTINCT FROM en lloc de <>. És directament 04-03: si productes.cost fos NULL, la comparació productes.cost <> EXCLUDED.cost donaria UNKNOWN, el WHERE la descartaria i el cost no s'actualitzaria mai. IS DISTINCT FROM tracta dos nuls com a iguals i un nul davant d'un valor com a diferents, que és el que aquí necessitem. És un dels llocs on aquella lliçó es cobra el deute.

RETURNING funciona igual que a INSERT i UPDATE: retorna les files afectades, tant si són inserides com actualitzades. El que no et diu de manera directa és quina va ser quina.

Existeix un truc molt estès basat en la columna de sistema xmax (exemple sobre la base acabada de recarregar):

La Lucía s'ha actualitzat (false), la Marisol s'ha creat (true) — amb l'id 17, perquè l'intent fallit sobre la Lucía es va endur el 16.

Com funciona. xmax és una columna oculta que PostgreSQL fa servir internament per al control de versions: desa l'identificador de la transacció que va esborrar o bloquejar la fila. En una fila acabada d'inserir val 0; en una d'actualitzada dins de l'upsert, no.

⚠️ Fes-lo servir amb reserves. xmax és un detall d'implementació, no una interfície documentada. Pot canviar entre versions, i hi ha situacions (files bloquejades per altres transaccions, SELECT ... FOR UPDATE previs) en què un xmax diferent de zero no significa el que et penses. Serveix perfectament per depurar i per a un informe intern; no construeixis lògica de negoci crítica sobre ell.

I una limitació que sí que importa: amb DO NOTHING, les files en conflicte no apareixen al RETURNING en absolut. Només veuràs les que realment s'han inserit:

Una de les dues. Si necessites saber també què s'ha ignorat, DO NOTHING no t'ho dirà.

ON CONFLICT és una extensió de PostgreSQL. L'estàndard SQL:2003 defineix per al mateix la instrucció MERGE, que PostgreSQL va incorporar a la versió 15.

La lògica és la d'un JOIN: s'aparellen destinació i origen per la condició de l'ON, i per a cada fila s'executa la primera clàusula WHEN que es compleixi.

L'origen pot ser una taula, una consulta o una llista de valors. Per al cas de BotigaVerda, el natural és una taula de staging amb el contingut del fitxer del proveïdor:

Aquell COPY a una taula de staging seguit d'una fusió cap a la taula definitiva és el patró professional d'integració de dades que anunciava 05-02.

I ara el mateix cas de l'apartat 7, resolt amb MERGE:

Quatre files afectades: tres actualitzacions (oli, tomàquet i kombutxa) i una inserció (cigrons). L'arròs no compleix la condició del WHEN MATCHED i, en no haver-hi més clàusules aplicables, es queda com està.

Fixa't en el suc de taronja (17): és de Huerta del Turia però no venia al fitxer, i ha quedat intacte. Ni ON CONFLICT ni aquest MERGE no fan res amb les files de la destinació que l'origen no esmenta. Si el criteri de negoci fos "el que no és al fitxer es descataloga", caldrien dues operacions… o una clàusula WHEN NOT MATCHED BY SOURCE, que PostgreSQL 16 encara no té (va arribar a la 17).

Diverses condicions i DELETE. Aquest MERGE sincronitza el catàleg i a més descataloga el que el proveïdor envia a preu 0:

Tres regles diferents en una sentència, avaluades en ordre: la primera que es compleixi guanya. Amb ON CONFLICT això no es pot expressar; caldrien diverses sentències.

Aquella tercera limitació és contraintuïtiva i convé retenir-la: la instrucció estàndard és menys robusta davant de la concurrència que l'extensió propietària, perquè ON CONFLICT es recolza directament en l'índex únic i MERGE no l'exigeix.

Quan fer servir cadascun:

• ON CONFLICT quan el cas sigui el clàssic "inserir o actualitzar" sobre una clau única, quan hi hagi concurrència real, o quan necessitis RETURNING. És el 90 % dels casos.
• MERGE quan necessitis diverses regles (actualitzar-ne uns, esborrar-ne d'altres, inserir la resta), quan l'aparellament no sigui per una clau única, quan l'origen sigui una consulta complexa, o quan el codi hagi de ser portable a Oracle o SQL Server.

SQLite ofereix a més INSERT OR REPLACE INTO ..., que molta gent fa servir creient que és un upsert. No ho és, i la diferència és greu:

Aplicat a BotigaVerda seria una catàstrofe silenciosa: un INSERT OR REPLACE sobre productes esborraria la fila, i amb ella se n'anirien en cascada totes les seves ressenyes (ressenyes.producte_id és ON DELETE CASCADE). L'"upsert" hauria destruït dades d'una altra taula sense esmentar-la.

La regla: a SQLite fes servir ON CONFLICT ... DO UPDATE, mai INSERT OR REPLACE, llevat que l'esborrat-i-recreació sigui exactament el que vols.

Resolt als apartats 7 i 9, de les dues formes. Requereix la restricció uq_productes_nom per a la versió amb ON CONFLICT; el MERGE funcionaria igual sense ella.

Resolt a l'apartat 6 amb el patró d'acumulació SET stock = productes.stock + EXCLUDED.stock. És el cas on l'upsert brilla: una sola sentència processa un albarà sencer, tant si dóna d'alta referències noves com si suma a les existents.

Una versió més completa, que a més actualitza el preu de compra i anota la data d'alta només a les referències noves:

Quatre acumulacions i una alta. I observa la columna data_alta: les quatre existents conserven la seva (2025) i només la nova estrena la d'avui, perquè data_alta no apareix al SET. Aquella asimetria —uns camps es fusionen i altres només s'omplen en crear— és just el que fa útil el DO UPDATE davant d'un REPLACE.

Fixa't també que l'origen és un SELECT, no un VALUES. INSERT ... SELECT ... ON CONFLICT combina el de 05-02 amb el d'aquesta lliçó, i és la forma habitual de processar una taula de staging sencera.

Un client torna a valorar un producte que ja havia ressenyat. La regla de negoci: una ressenya per client i producte, i l'última substitueix l'anterior.

Avui ressenyes no impedeix duplicats, així que primer cal declarar aquella regla:

Funciona perquè les dotze ressenyes actuals tenen parells (producte_id, client_id) diferents. Si hi hagués duplicats, l'ALTER TABLE fallaria — que és exactament el que ha de fer.

Ara l'upsert. El client 6 (Pau Llorens Vidal) havia posat un 2 a la Kombutxa; n'han canviat la recepta i vol pujar-lo a 4:

Mateixa fila (id 6), contingut nou. I amb un client que no ha ressenyat mai aquell producte, la mateixa sentència crea la ressenya:

L'id és 14 i no 13 pel mateix de l'apartat 4: l'upsert anterior, que va acabar en DO UPDATE, ja s'havia endut el 13 de la seqüència.

I l'efecte sobre la valoració del producte:

D'un 2 solitari a una mitjana de 4,50 amb dues ressenyes. La Kombutxa deixa de ser el pitjor producte del catàleg.

Recorda desfer els exemples. Les dues restriccions d'aquesta lliçó (uq_productes_nom i uq_ressenyes_producte_client) no formen part de l'esquema del curs. Treu-les amb ALTER TABLE ... DROP CONSTRAINT ... o, més simple, recarrega botigaverda.sql. La sintaxi completa d'ALTER TABLE és la lliçó següent.

• Resoldre l'upsert amb SELECT + INSERT/UPDATE. Condició de cursa garantida sota concurrència. Una sentència és atòmica; dues no.
• Fer servir ON CONFLICT sobre columnes sense restricció única. there is no unique or exclusion constraint matching the ON CONFLICT specification. L'índex únic és el mecanisme, no un requisit burocràtic.
• Oblidar el prefix EXCLUDED. al DO UPDATE. SET preu = preu és una assignació circular: la fila es queda com estava i no dóna error.
• Portar el mateix valor de clau dues vegades a la mateixa sentència. cannot affect row a second time. Dedupica l'origen abans.
• Comparar amb <> en lloc d'IS DISTINCT FROM al WHERE del DO UPDATE. Amb un NULL pel mig la comparació dóna UNKNOWN i la fila no s'actualitza mai (04-03).
• Esperar que DO NOTHING t'informi del que ha ignorat. No apareix al RETURNING. Si necessites saber-ho, fes servir DO UPDATE amb WHERE.
• Construir lògica de negoci sobre xmax = 0. És un detall d'implementació. Val per depurar; no per facturar.
• Creure que l'upsert actualitza també el que l'origen no esmenta. No ho fa. Les files de la destinació absents del fitxer queden intactes.
• Fer servir INSERT OR REPLACE a SQLite creient que és un upsert. Esborra i recrea: perd columnes, canvia el rowid i dispara les cascades d'esborrat.
• Suposar que MERGE és segur davant de la concurrència. No ho és a PostgreSQL 16: pot fallar amb clau duplicada. ON CONFLICT sí que ho és.
• Consell: per a un albarà o un fitxer, carrega a una taula de staging i fusiona des d'allà. COPY + INSERT ... SELECT ... ON CONFLICT (o MERGE) és el patró professional d'integració.
• Consell: decideix camp a camp què es fusiona. preu sí, data_alta no, stock acumulant. Aquella granularitat és tot el valor del DO UPDATE.
• Consell: posa sempre el WHERE ... IS DISTINCT FROM al DO UPDATE. Menys escriptures, menys bloqueigs, auditoria honesta i un RETURNING que diu la veritat.

Treballa sobre la base acabada de recarregar, dins de BEGIN … ROLLBACK.

BotigaVerda rep un fitxer d'altes i baixes de clients procedent d'una campanya de màrqueting:

Escriu una sola sentència que doni d'alta els que no existeixin i actualitzi la ciutat dels que sí, amb aquestes regles:

1. data_registre ha de ser 2026-03-02 per als nous i no s'ha de modificar en els existents.
2. La ciutat només s'ha d'actualitzar si realment canvia.
3. El resultat ha d'indicar, per fila, si va ser alta o modificació.

Després respon: quantes files retorna el RETURNING i per què?

Resol el mateix cas de l'exercici 1 amb MERGE, carregant abans les dades en una taula temporal clients_campanya. Després compara les dues solucions responent aquestes preguntes:

1. Quina diferència hi ha en la sortida de psql?
2. Quina de les dues és segura si dos processos executen la campanya alhora?
3. Quina escriuries si a més calgués desactivar els clients que no apareixen al fitxer? Es pot fer a PostgreSQL 16?

Un company vol sincronitzar el catàleg i escriu això:

Té tres errors diferents. Troba'ls, explica el símptoma de cadascun i reescriu la sentència correctament, indicant què hauria d'estar declarat a l'esquema perquè funcionés i quin resultat donaria.

Solució 1

Quatre files, i no és casualitat que surtin les quatre:

Si el fitxer hagués portat la Lucía amb la seva ciutat actual (València), el WHERE ... IS DISTINCT FROM hauria descartat aquella actualització i el RETURNING hauria retornat tres files.

Les tres decisions de l'enunciat:

1. data_registre fora del SET. Apareix a l'INSERT (per als nous) però no al DO UPDATE, així que els existents conserven la seva: 2025-01-10 i 2025-03-21. És el mateix principi que amb data_alta a 12.2.
2. WHERE clients.ciutat IS DISTINCT FROM EXCLUDED.ciutat, no <>: si algun client tingués la ciutat a NULL (la columna ho admet), <> donaria UNKNOWN i no s'actualitzaria mai.
3. (xmax = 0) AS alta_nova, amb la reserva de l'apartat 8: serveix per a l'informe de la campanya, no per a lògica crítica.

Solució 2

Resultat idèntic en el contingut, amb un detall revelador als id: aquí són 16 i 17, no 18 i 19 com amb ON CONFLICT. El motiu és que MERGE només avalua els DEFAULT de les files que realment insereix, mentre que l'upsert els avalua també a les que acaben en conflicte. MERGE malgasta menys valors de seqüència. (Amb tot, no comptis amb id consecutius en cap dels dos: les seqüències tenen buits per disseny.)

Les tres respostes:

1. La sortida. MERGE 4 davant d'INSERT 0 4, i sobretot: el MERGE de PostgreSQL 16 no admet RETURNING, així que cal consultar després per veure què ha passat — i aquella consulta ja no pot distingir altes de modificacions. És la pèrdua més notable en canviar d'instrucció.

2. Concurrència. La segura és ON CONFLICT. Si dos processos llancen la campanya alhora, el MERGE pot fallar amb duplicate key value violates unique constraint "clients_email_key", perquè el seu aparellament no es recolza en l'índex únic de la mateixa manera. ON CONFLICT està dissenyat precisament per a aquell escenari.

3. Desactivar els absents. Seria la feina d'una clàusula WHEN NOT MATCHED BY SOURCE THEN UPDATE SET ..., que PostgreSQL 16 no té (va arribar a la 17). A la 16 cal fer-ho en dues sentències dins de la mateixa transacció: el MERGE (o l'upsert) i després un UPDATE ... WHERE email NOT IN (SELECT email FROM clients_campanya). Compte amb aquell NOT IN i els nuls: 04-02 ho va advertir, i aquí clients_campanya.email és PRIMARY KEY, així que és segur. A més, clients no té columna de baixa, així que a BotigaVerda l'operació ni tan sols seria expressable sense un ALTER TABLE previ — lliçó següent.

Solució 3

Els tres errors:

Hi ha un quart detall que no és un error de sintaxi però sí de criteri: SET stock = stock + EXCLUDED.stock funciona perquè stock sense qualificar es resol a la fila existent, però és ambigu de llegir. Escriu sempre productes.stock + EXCLUDED.stock.

Què caldria a l'esquema. Per aparellar per nom cal la restricció de l'apartat 5:

La versió corregida, amb l'origen deduplicat (ens quedem amb l'últim enviament de la mel, el de 10,50 €, i sumem les dues quantitats: 40 + 25 = 65):

Els dos productes existien (ids 3 i 4, de BioSierra Ibérica): la mel passa de 9,75 € a 10,50 € i de 80 a 145 unitats (80 + 65); la pasta passa de 2,80 € a 2,95 € i de 150 a 230 unitats (150 + 80).

I la lliçó de fons de l'exercici: dels tres errors, dos no produeixen cap missatge. L'ON CONFLICT (id) hauria duplicat el catàleg en silenci i el SET preu = preu hauria deixat els preus sense tocar sense que ningú no se n'assabentés. Només el tercer —el duplicat a l'origen— provoca un error visible. Un upsert mal escrit falla callat molt més sovint que sorollosament, i per això cal comprovar el RETURNING fila a fila la primera vegada que es posa en producció.

L'upsert resol l'operació que faltava:

• El problema: "insereix si no existeix, actualitza si existeix", omnipresent en sincronització de catàlegs, recepció de mercaderia, altes de client i valoracions.
• La solució ingènua és incorrecta: SELECT i després decidir obre una condició de cursa entre la comprovació i l'escriptura. Dues sessions veuen "no existeix" i totes dues insereixen. Una sentència és atòmica; dues no.
• INSERT ... ON CONFLICT, amb les seves dues accions: DO NOTHING (ideal per a dades mestres reexecutables, INSERT 0 0 sense error) i DO UPDATE SET (l'upsert pròpiament dit).
• La destinació del conflicte, per columna o per ON CONSTRAINT, i per què exigeix una restricció única: sense l'índex, PostgreSQL no podria decidir atòmicament i tornaria la finestra de cursa.
• EXCLUDED, la pseudotaula amb la fila proposada, davant de taula.columna amb la fila existent. D'aquí surten tots els patrons: quedar-se amb el nou, conservar el vell, GREATEST, i sobretot acumular (stock = productes.stock + EXCLUDED.stock). I el seu límit: el mateix valor de clau dues vegades en una sentència falla, cal deduplicar l'origen.
• WHERE al DO UPDATE amb IS DISTINCT FROM (04-03) per no escriure quan no canvia res: menys escriptures, menys bloqueigs, auditoria honesta.
• RETURNING amb upsert, i el truc de xmax = 0 per distingir alta de modificació, amb les seves reserves.
• MERGE, l'estàndard SQL:2003 disponible des de PostgreSQL 15: WHEN MATCHED / WHEN NOT MATCHED, diverses condicions avaluades en ordre i la capacitat d'esborrar. Amb les seves tres limitacions a PostgreSQL 16: sense RETURNING, sense WHEN NOT MATCHED BY SOURCE, i no immune a la concurrència.
• Quan fer servir cadascun: ON CONFLICT per al cas clàssic amb concurrència real; MERGE per a regles múltiples, aparellaments sense clau única i portabilitat.
• El suport per motor, i l'avís sobre INSERT OR REPLACE de SQLite, que esborra i recrea la fila: perd columnes, canvia el rowid i dispara les cascades d'esborrat.

Amb això has tancat el DML: saps crear, llegir, inserir, modificar, esborrar i fusionar. Tot això sobre un esquema que fins ara ha estat immutable: el mateix que vas crear a 05-01 i que no has tornat a tocar. Però els esquemes canvien. Cal una columna nova, un tipus es queda curt, una restricció arriba tard, un nom resulta ser un error. A l'última lliçó del mòdul, Modificar l'esquema: ALTER TABLE i migracions segures, aprendràs totes les operacions d'ALTER TABLE i —el que de debò separa una migració innòcua d'una caiguda de producció— quines bloquegen la taula i quines no, el patró expand/contract per canviar un esquema sense aturar el servei, i per què cap canvi d'estructura no s'hauria d'escriure mai a mà en una consola de producció.