Re: INSERT ... ON CONFLICT DO UPDATE
От | Rafal Pietrak |
---|---|
Тема | Re: INSERT ... ON CONFLICT DO UPDATE |
Дата | |
Msg-id | 55AB5BBD.8@ztk-rp.eu обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT DO UPDATE ("Charles Clavadetscher" <clavadetscher@swisspug.org>) |
Ответы |
Re: INSERT ... ON CONFLICT DO UPDATE
|
Список | pgsql-general |
Hi, W dniu 19.07.2015 o 09:33, Charles Clavadetscher pisze: [---------------] >> 2. with current (as of 9.5) implementation I think I can always "ON CONFLICT >> DO NOTHING", and retry the INSERT from application level. > > An UPSERT is "try an INSERT and if there is a conflict, do nothing or UPDATE some values of the existing record". The scenariothat you suggest is not an UPSERT, because what you want to reach is to try a new INSERT, hoping that this works. > What speak against using a sequence for the primary key column a_voucher? This would guarantee that you don't have a conflict. > It have to be random, since it barres a "sort of monetary" value. The vouches are destined to be one-time authorization tokens, they have to be harder to guess then those drawn from the sequence are. [------------] >> >> If not: is it unreasonable? why? > > IMHO, as I mentioned, this is not an UPSERT use case, but maybe the implementors of the feature may have different arguments.You could implement that in a function instead of the application, if you prefer. > I'm not particularly fond of using functions to accessing RDBMS instead of tables. And I'm not particularly fond of "workarounds". But if that usage scenario is not appreciated here, then guess I have to live with what is available. And the availability of ON CONFLICT is a great improvement anyway. Thenx, -R
В списке pgsql-general по дате отправления: