Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint

Поиск
Список
Период
Сортировка
От Geoff Winkless
Тема Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint
Дата
Msg-id CAEzk6feWyUSRTSx4FnTuApeV2=N1Opt9pApSdLBk_+R1rzLNpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint  (Peter Geoghegan <pg@heroku.com>)
Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Дерево обсуждения
On 19 May 2015 at 21:12, Peter Geoghegan <pg@heroku.com> wrote:
It's trivial to modify Postgres to not require that a specific unique
index be inferred, so that you can omit the inference specification
for DO UPDATE just as you can for DO NOTHING. That would make it work
in a similar way to MySQL; whatever actually conflict was detected
would be assumed to be cause to take the alternative update path.

​Except that would break the deterministic behaviour, surely? Because if you only updated one row based on which constraint matched first, the row that was updated would depend on the order in which the constraints were evaluated, yes? I was expecting that matching two constraints would end up UPDATEing two separate rows.

I have a hard time imagining why you'd ever not want to be explicit
about what to take the alternative path on for the DO UPDATE variant.

What do you have in mind?

If I'm being honest, my main driver is laziness :) I don't mind specifying the constraint if I can understand why it's required, but otherwise it just seems like I need to do more typing for no reason. Especially when there's only one unique constraint on a table.

Geoff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION