Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id CAM3SWZT01QF9taV-4q-0370CND=LxESaHTZYU7Pz3q4hRXa_kQ@mail.gmail.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Dec 23, 2014 at 5:46 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 22, 2014 at 5:04 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> If you're dead set on having an escape hatch, maybe we should just get
>> over it and add a way of specifying a unique index by name. As I said,
>> these under-served use cases are either exceedingly rare or entirely
>> theoretical.
>
> I'm decidedly unenthusiastic about that.  People don't expect CREATE
> INDEX CONCURRENTLY + DROP INDEX CONCURRENTLY to break their DML.  I
> think the solution in this case would be a gateway to problems larger
> than the one we're trying to solve.

I tend to agree. I think we should just live with the fact that not
every conceivable use case will be covered, at least initially. Then,
if an appreciable demand for even more flexibility emerges, we can
revisit this. We already have a syntax that is significantly more
flexible than the equivalent feature in any other system. Let's not
lose sight of that.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Commit timestamp abbreviations
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}