4 ms·
In my experience this tends to be an annoyance when you want to upsert against a table that has multiple unique constraints. For example, let's say you're trac
by richbell 3y ago
In my experience this tends to be an annoyance when you want to upsert against a table that has multiple unique constraints.
For example, let's say you're tracking GitHub repositories and have a table `repository(id, gh_id, gh_node_id, owner, name, description)` where `gh_id` and `gh_node_id` are both unique.
If you want to insert or update a repository you might want to do something like below, however, this is not a valid syntax and as you need to define a separate `DO UPDATE` for `gh_id` and `gh_node_id`:
INSERT INTO repository (gh_id, gh_node_id, owner, name, description)
VALUES (:id, :node_id, :owner, :name, :description)
ON CONFLICT DO UPDATE
SET name = excluded.name,
description = excluded.description;
------
To my knowledge there's no way to define a single constraint `UNIQUE(gh_id || gh_node_id)` instead of `UNIQUE(gh_id && gh_node_id)`.
- paulddraper 3y agoSo....what is gh_id and gh_node_id? Like, you have gh_id | gh_node_id ------------------ 1 | 2 2 | 1 And then you want to "upsert" (1, 1). You want both records to be updated? I'm still struggling to see why you would want to do a upsert relative to multiple unique constraints at once.
- cropcirclbureau 3y agoAh, I'd run into the lack of multi constraint ON CONFLICT in postgres yesterday and was wondering about the omission. I'd not considered this case and GP's code smell comment makes sense now. In my specific case, business logic dictates uniqueness of both columns is tied together i.e. if an incoming tuple has a value (1, 2) today, all subsequent expected tuples with `gh_id` 1 will also have `gh_node_id` of 2. What's the best practice to model this constraint?
- paulddraper 3y agoThen upsert based on gh_id. I'm not saying that multiple unique identifiers is a code smell; I am claiming that an upsert is only sensibly done in the context of one constraint.