就我个人而言，我已经设置了一个附加到插入语句的“规则”。假设你有一个“dns”表，记录每个客户每次的dns点击量:

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

您希望能够重新插入具有更新值的行，或者在这些行不存在时创建它们。输入customer_id和时间。就像这样:

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

更新:如果同时进行插入，则有可能失败，因为它将生成unique_violation异常。但是，未终止的事务将继续并成功，您只需要重复已终止的事务。

然而，如果一直都有大量的插入发生，你会想在插入语句周围放一个表锁:SHARE ROW EXCLUSIVE锁将阻止任何可能在目标表中插入、删除或更新行的操作。但是，不更新唯一密钥的更新是安全的，因此如果没有操作将这样做，则使用建议锁。

此外，COPY命令不使用RULES，因此如果使用COPY进行插入，则需要使用触发器。

根据INSERT语句的PostgreSQL文档，不支持处理ON DUPLICATE KEY情况。这部分语法是一个专有的MySQL扩展。

在PostgreSQL 9.1中，这可以使用可写的CTE(公共表表达式)来实现:

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)

看看这些博客:

通过可写CTE上传 等待9.1 -可写cte 为什么upsert这么复杂?

请注意，此解决方案不能防止唯一键违反，但不容易丢失更新。 请在dba.stackexchange.com上查看Craig Ringer的后续报道

就我个人而言，我已经设置了一个附加到插入语句的“规则”。假设你有一个“dns”表，记录每个客户每次的dns点击量:

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

您希望能够重新插入具有更新值的行，或者在这些行不存在时创建它们。输入customer_id和时间。就像这样:

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

更新:如果同时进行插入，则有可能失败，因为它将生成unique_violation异常。但是，未终止的事务将继续并成功，您只需要重复已终止的事务。

然而，如果一直都有大量的插入发生，你会想在插入语句周围放一个表锁:SHARE ROW EXCLUSIVE锁将阻止任何可能在目标表中插入、删除或更新行的操作。但是，不更新唯一密钥的更新是安全的，因此如果没有操作将这样做，则使用建议锁。

此外，COPY命令不使用RULES，因此如果使用COPY进行插入，则需要使用触发器。

警告:如果同时从多个会话执行，这是不安全的(参见下面的警告)。

在postgresql中执行“UPSERT”的另一个聪明方法是执行两个连续的UPDATE/INSERT语句，每个语句都被设计为成功或没有效果。

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

如果已经存在“id=3”的行，则UPDATE将成功，否则将不起作用。

只有当“id=3”的行不存在时，INSERT才会成功。

您可以将这两个组合到一个字符串中，并通过从应用程序执行的单个SQL语句同时运行它们。强烈建议在一个事务中同时运行它们。

This works very well when run in isolation or on a locked table, but is subject to race conditions that mean it might still fail with duplicate key error if a row is inserted concurrently, or might terminate with no row inserted when a row is deleted concurrently. A SERIALIZABLE transaction on PostgreSQL 9.1 or higher will handle it reliably at the cost of a very high serialization failure rate, meaning you'll have to retry a lot. See why is upsert so complicated, which discusses this case in more detail.

这种方法在读提交隔离中还可能导致更新丢失，除非应用程序检查受影响的行数，并验证插入或更新是否影响了行。

对于合并小集合，可以使用上面的函数。但是，如果您正在合并大量数据，我建议您查看http://mbk.projects.postgresql.org

目前我所知道的最佳实践是:

复制新的/更新的数据到临时表(当然，或者你可以做INSERT，如果成本是ok) 获得锁[可选](建议优先于表锁，IMO) 合并。(有趣的部分)