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