From: | Rafal Pietrak <rafal(at)ztk-rp(dot)eu> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: INSERT ... ON CONFLICT DO UPDATE |
Date: | 2015-07-19 15:04:54 |
Message-ID: | 55ABBC96.4020705@ztk-rp.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
W dniu 19.07.2015 o 16:33, Adrian Klaver pisze:
> On 07/19/2015 06:47 AM, Rafal Pietrak wrote:
>> Hi,
>>
>> W dniu 19.07.2015 o 14:10, Geoff Winkless pisze:
>>> On 19 July 2015 at 11:30, Rafal Pietrak <rafal(at)ztk-rp(dot)eu
[---------------]
>> Although "a random" can duplicate its previous values, "my random(s)"
>> (which are created for this application purpose) cannot be duplicated
>> when it's stored in the database as "live active data". I understand,
>> that UNIQUE constraint is precisely the RDBMS tool to guarantee that.
>
> From my perspective the issue is, you are using a 'unique' key generator
> that you know is not creating unique keys and then asking the database
> to make it right. Sort of like making a square peg fit a round hole by
> shaving the corners. It is possible but has sort of a messy feel to it.
Hmmm, yes.
Yet, I don't feel guilty as much, since that is quite similar to a
unique key on database "username", while the "generator" (human mind)
does not guarantee that. The DB just makes sure it does.
[--------------]
>
> So an UPSERT is just one feature of ON CONFLICT. The other being DO
> NOTHING. Therefore I could see an argument made for adding other ON
> CONFLICT clauses. How difficult/plausible that would be is above my
> level of expertise.
>
Mine too. But I'd say that the above wording exactly makes the point I
was trying to make. Thank you.
-R
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-19 15:09:31 | Re: IO in constraint trigger |
Previous Message | Adrian Klaver | 2015-07-19 14:33:21 | Re: INSERT ... ON CONFLICT DO UPDATE |