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 ]
Jeff Davis pg...@j-davis.com 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
On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com 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)
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Sep 27, 2009 at 1:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 23, 2009 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that USING is just about as content-free as WITH in this
particular example --- it doesn't give you any hint
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com 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:
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
Jeff Davis pg...@j-davis.com 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
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
Jeff Davis pg...@j-davis.com 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
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 = , b
Jeff Davis pg...@j-davis.com 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
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 pg...@j-davis.com 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
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 going
Jeff Davis pg...@j-davis.com writes:
I believe that syntax is possible by specifying the index access method,
e.g.:
CONSTRAINT name EXCLUSION (a =, b ) USING gist;
versus:
CONSTRAINT name EXCLUSION (a =, b ) INDEX indexname;
And the former could build the index implicitly. I haven't
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
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 name]
Jeff Davis pg...@j-davis.com writes:
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT name] EXCLUSION (expr OPERATOR op, ...)
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
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT name] EXCLUSION (expr OPERATOR op, ...)
Have you actually built this grammar? I don't think it avoids the
problem, because OPERATOR is
Jeff Davis pg...@j-davis.com 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
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
On Sat, 2009-09-19 at 10:48 -0700, Jeff Davis wrote:
CONSTRAINT foo_constr (a op, ...)
{ USING INDEX foo_idx | USING method }
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a op, ...) { USING method | INDEX foo_idx };
First, I think EXCLUSION makes a perfect noun
Jeff Davis pg...@j-davis.com writes:
I am updating the syntax to be:
CONSTRAINT foo_constr
EXCLUSION (a op, ...) { 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
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
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.
26 matches
Mail list logo
