Re: INSERT ... ON CONFLICT DO UPDATE
От | Rafal Pietrak |
---|---|
Тема | Re: INSERT ... ON CONFLICT DO UPDATE |
Дата | |
Msg-id | 55ABBC96.4020705@ztk-rp.eu обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT DO UPDATE (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: INSERT ... ON CONFLICT DO UPDATE
|
Список | pgsql-general |
W dniu 19.07.2015 o 16:33, Adrian Klaver pisze: > On 07/19/2015 06:47 AM, Rafal Pietrak wrote: >> Hi, >> >> W dniu 19.07.2015 o 14:10, Geoff Winkless pisze: >>> On 19 July 2015 at 11:30, Rafal Pietrak <rafal@ztk-rp.eu [---------------] >> Although "a random" can duplicate its previous values, "my random(s)" >> (which are created for this application purpose) cannot be duplicated >> when it's stored in the database as "live active data". I understand, >> that UNIQUE constraint is precisely the RDBMS tool to guarantee that. > > From my perspective the issue is, you are using a 'unique' key generator > that you know is not creating unique keys and then asking the database > to make it right. Sort of like making a square peg fit a round hole by > shaving the corners. It is possible but has sort of a messy feel to it. Hmmm, yes. Yet, I don't feel guilty as much, since that is quite similar to a unique key on database "username", while the "generator" (human mind) does not guarantee that. The DB just makes sure it does. [--------------] > > So an UPSERT is just one feature of ON CONFLICT. The other being DO > NOTHING. Therefore I could see an argument made for adding other ON > CONFLICT clauses. How difficult/plausible that would be is above my > level of expertise. > Mine too. But I'd say that the above wording exactly makes the point I was trying to make. Thank you. -R
В списке pgsql-general по дате отправления: