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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
