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
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 |