Hi,
W dniu 19.07.2015 o 10:27, Geoff Winkless pisze:
> On 19 July 2015 at 09:11, Rafal Pietrak <rafal@ztk-rp.eu
> <mailto:rafal@ztk-rp.eu>> wrote:
>
> I'm not particularly fond of using functions to accessing RDBMS instead
> of tables.
>
> And I'm not particularly fond of "workarounds".
>
>
> Use a combination of factors (a sequence ID and the key) for your
> authorization. So in the extremely unlikely event that the random key
> isn't unique, it doesn't matter. That's not a workaround, it's good design.
I'm sory. At this point I don't want to prolong the discussion (like
flaming), but I feel like having to defend myself a little.
Regarding the above: when I have to invent/introduce additional
features/columns/attributes (like a key in addition to a sequence),
which are not required by the design, but necessary for implementation)
is a workaround (almost by definition).
In my current implementations I captures (the rare) PK conflict
exceptions and redo the INSERT at application level. It works
sufficiently well. I was just curious if that usage scenario is
currently also covered by current ON CONFLICT, or not.
>
> You're asking for a feature that is completely unnecessary and is easily
> resolved. UPSERT is designed for a situation which is neither.
>
1. Despite possibly sounding like one, I wasn't actually asking for a
feature - I wasn't sure if that could possibly be implemented using
currently available postresql features. So I've just explained a usage
scenario (explaining the semantics using "invented pseudo syntax") which
I've experienced.
2. that usage scenario, IMHO wasn't obviously covered (as of my first
reading of "the upsert" implementation). It might have been covered ...
only I wasn't seeing it; so I've brought it up.
3. and obviously that usage scenario (despite my personal experience)
might actually be very rare - unworthy implementation effort and thus
qualifying for workarounds. This happen, I understand.
I hope this explains my point better.
-R
