Re: INSERT ... ON CONFLICT DO UPDATE

From: Rafal Pietrak <rafal(at)ztk-rp(dot)eu>
To: Charles Clavadetscher <clavadetscher(at)swisspug(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: INSERT ... ON CONFLICT DO UPDATE
Date: 2015-07-19 08:11:41
Message-ID: 55AB5BBD.8@ztk-rp.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 scenario that 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Geoff Winkless 2015-07-19 08:27:50 Re: INSERT ... ON CONFLICT DO UPDATE
Previous Message Charles Clavadetscher 2015-07-19 07:33:44 Re: INSERT ... ON CONFLICT DO UPDATE