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

From Stephen Frost
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id 20141223193633.GP3062@tamriel.snowman.net
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
* Peter Geoghegan (pg@heroku.com) wrote:
> 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.

+1
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: José Luis Tallón
Date:
Subject: Re: Proposal: two new role attributes and/or capabilities?