Jeff Davis writes:
> I tried to move the WHERE clause right before or after the
> index_parameters, but that resulted in shift/reduce conflicts.
You could avoid the conflicts in at least two ways:
* require parens around the WHERE expression
* stick the WHERE inside the EXCLUSION ( ... ) bit, s
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
> (I'm wondering a bit if anyone will want a WHERE clause, too, though
> adding that later shouldn't pose any big syntactic obstacles.)
Where should I put the WHERE clause? My current syntax (with patch) is:
[ CONSTRAINT constraint_name ]
EXCLU
On Sun, Sep 27, 2009 at 1:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane wrote:
>>> I think that USING is just about as content-free as WITH in this
>>> particular example --- it doesn't give you any hint about what the
>>> purpose of the operator is.
>
Robert Haas writes:
> On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane wrote:
>> I think that USING is just about as content-free as WITH in this
>> particular example --- it doesn't give you any hint about what the
>> purpose of the operator is.
> USING might be just as content-free as WITH, but USING
On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane wrote:
> Jeff Davis writes:
>> We can either eliminate the USING variant from opt_class (unless it's
>> necessary for some reason or I missed it in the documentation), or we
>> can use another word (e.g. WITH or WITH OPERATOR) if you don't like
>> CHECK.
Jeff Davis writes:
> We can either eliminate the USING variant from opt_class (unless it's
> necessary for some reason or I missed it in the documentation), or we
> can use another word (e.g. WITH or WITH OPERATOR) if you don't like
> CHECK.
Hmm ... we don't seem to have documented the USING nois
On Wed, 2009-09-23 at 15:10 +0300, Peter Eisentraut wrote:
> Using CHECK as part of the syntax of an EXCLUSION constraint will surely
> confuse the whole thing with CHECK constraints.
>
> USING OPERATOR is available, I think.
USING won't work because one of the ways to specify the opclass in an
i
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > I suppose I should just allow any index_elem. The only way I was able to
> > make the grammar for that work is by using a reserved keyword. The
> > possibilities that make the most sense to me are:
>
> > index_elem WITH
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
> BTW, are you sure EXCLUSION doesn't have to become a reserved word for
> this? I notice that FOREIGN, CHECK, and UNIQUE all are, which makes me
> suspicious ...
All of those (except FOREIGN) can be used as a column constraint as
well, and that
Jeff Davis writes:
> I suppose I should just allow any index_elem. The only way I was able to
> make the grammar for that work is by using a reserved keyword. The
> possibilities that make the most sense to me are:
> index_elem WITH any_operator
> index_elem WITH OPERATOR any_operator
> ind
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > 1. Constraint syntax, part of CREATE/ALTER TABLE:
>
> > [CONSTRAINT ] EXCLUSION ( OPERATOR , ...)
>
> Have you actually built this grammar? I don't think it avoids the
> problem, because OPERATOR is possible within a_
Jeff Davis writes:
> 1. Constraint syntax, part of CREATE/ALTER TABLE:
> [CONSTRAINT ] EXCLUSION ( OPERATOR , ...)
Have you actually built this grammar? I don't think it avoids the
problem, because OPERATOR is possible within a_expr.
Also, don't forget the possibility of wanting a nondefault
Update on operator exclusion constraints (OXC for short):
After a lot of discussion, I think a lot of progress has been made. Here
is my summary, please let me know if I've left anything out or not
addressed some concern.
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT ] EXCLUSIO
On Sun, 2009-09-20 at 13:49 -0400, Tom Lane wrote:
> I'd vote for only supporting the former.
Ok.
I just did some brief non-scientific in-memory benchmarks. I think it
has promise, but for now I think it can safely be set aside.
Results appended.
> What worries me more about that syntax is the
Jeff Davis writes:
> I believe that syntax is possible by specifying the index access method,
> e.g.:
> CONSTRAINT EXCLUSION (a =, b &&) USING gist;
> versus:
> CONSTRAINT EXCLUSION (a =, b &&) INDEX ;
> And the former could build the index implicitly. I haven't written the
> code yet, b
On Sun, 2009-09-20 at 13:28 -0400, Tom Lane wrote:
> What I'm arguing for is a syntax in which the question doesn't even
> arise, ie, a CONSTRAINT doesn't reference an existing index at all.
> If that's not possible for whatever reason, then I think that
> disallowing multiple references isn't goin
Jeff Davis writes:
> On Sun, 2009-09-20 at 13:13 -0400, Tom Lane wrote:
>> You're right, it still seems remarkably marginal. I'm rethinking
>> my position on use of CONSTRAINT syntax because of the deferrability
>> issue, but I'm still unconvinced that we need to allow the constraints
>> to be de
On Sun, 2009-09-20 at 13:13 -0400, Tom Lane wrote:
> You're right, it still seems remarkably marginal. I'm rethinking
> my position on use of CONSTRAINT syntax because of the deferrability
> issue, but I'm still unconvinced that we need to allow the constraints
> to be decoupled from the indexes.
Jeff Davis writes:
> My use case was something else:
> An index on (a, b, c) enforcing the constraints UNIQUE(a, b) and
> UNIQUE(a, c).
> UNIQUE(a, b) can be enforced efficiently. UNIQUE(a, c) might be less
> efficient depending on the selectivity of "a", but as long as "a" is
> selective I thin
On Sun, 2009-09-20 at 12:45 -0400, Tom Lane wrote:
> How often have we had requests to add or drop UNIQUE in an existing
> index? Maybe there were more than zero, but not by a lot.
Ok.
> As an example of why I don't believe the first item, consider something
> like
> create index ... (a =
Jeff Davis writes:
> 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
>
On Sat, 2009-09-19 at 19:23 -0700, David Fetter wrote:
> It just occurred to me that SQL:2008 ASSERTION might already fit this
> feature. :)
I think I would only be able to enforce very specific types of
assertions that match the template. As I said to Robert, I think I'm
going to use ALTER INDEX
On Sat, Sep 19, 2009 at 04:40:19PM -0700, Jeff Davis wrote:
> 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. F
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 b
Jeff Davis writes:
> I am updating the syntax to be:
> CONSTRAINT foo_constr
> EXCLUSION (a , ...) { USING method | INDEX foo_idx };
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 infor
On Sat, 2009-09-19 at 10:48 -0700, Jeff Davis wrote:
> CONSTRAINT foo_constr (a , ...)
> { USING INDEX foo_idx | USING method }
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a , ...) { USING method | INDEX foo_idx };
First, I think EXCLUSION makes a perfect noun to
26 matches
Mail list logo
