On Sat, 2009-09-19 at 18:35 -0400, Tom Lane wrote:
> I'm still acutely uncomfortable with using CONSTRAINT syntax for this.
> It is not a constraint per standard, because it's not going to be
> displayable in information_schema. Furthermore, by extending
> standardized syntax you run the risk of being blindsided by future
> additions to the standard.
Ok.
> The point about being able to support multiple constraints with one
> index is kind of interesting, but I don't actually think that that's
> so useful that it should override all other considerations about what
> syntax we should pick. I think we should drop the whole thing and
> just treat this as an extension to the CREATE INDEX syntax.
Perhaps ALTER INDEX ADD EXCLUSION CONSTRAINT or some other command? And
CREATE INDEX can offer the ability as a shorthand?
I would still really like to decouple this from CREATE INDEX because of
two reasons:
1. Cannot support multiple constraints per index very easily. I think
this is a significant feature.
2. Must decide to make constraint at the same time as making the
index, and once it's there, you can't remove it without dropping
the index.
I think either of these still tie the concept to implementation, because
creating the index is always explicit. Peter seemed concerned about
that, and I think that concern is valid, but I can live with it. If we
really want them to be declarative, we could invent a new command.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
