Hi, W dniu 19.07.2015 o 10:27, Geoff Winkless pisze: > On 19 July 2015 at 09:11, Rafal Pietrak <rafal@xxxxxxxxx > <mailto:rafal@xxxxxxxxx>> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
