On Wed, May 6, 2015 at 1:22 PM, Andres Freund <andres@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.
>> 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.
Robert really disliked the idea of even naming the constraint, let
alone the index. I'm trying to balance things, here.
--
Peter Geoghegan
