On 2015-05-06 13:37:07 -0700, Peter Geoghegan wrote: > On Wed, May 6, 2015 at 1:22 PM, Andres Freund <and...@anarazel.de> wrote: > > That it supports exclusion constraints? > > But so does just naming the index. I don't think it's significant that > exclusion operators are in pg_constraint -- you could just as easily > name the index, since that's all you ultimately end up with anyway.
The index name for constraints is generated and not trivially safely guessable for a user. > >> I would care about the fact that you can't name a unique index with no > >> constraint if there wasn't already a way of doing that with inference > >> (I'm thinking in particular of partial indexes here, which never have > >> constraints). But there is. So what's the problem? > > > > Personally I think a complex expression index is something many people > > will not want to specify every time. And since partial/expression > > indexes can't even have constraints... > > The downsides seem severe. A CREATE INDEX CONCURRENTLY just broke > your statement, because you didn't account for the new, equivalent > unique index during inference, and now you have to drop the old index > and break application code. Is that really worth introducing just to > prevent app devs from writing the inference specification? The > specification explicitly documents their intent, which seems like a > good thing. I don't find that all that severe. It might just as well be the case that the new unique constraint isn't intended to be handled by ON CONFLICT. And having a inference specification that's longer than the rest of the statement surely isn't helpful. > Robert really disliked the idea of even naming the constraint, let > alone the index. I'm trying to balance things, here. I fail to see what doing something halfhearted helps. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
