|From:||Jeff Davis <pgsql(at)j-davis(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: operator exclusion constraints [was: generalized index constraints]|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
> 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
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
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.
|Next Message||Dimitri Fontaine||2009-09-20 00:03:45||Re: Anonymous code blocks|
|Previous Message||Jeff Davis||2009-09-19 22:53:54||Re: WIP: generalized index constraints|