On Thu, Mar 11, 2010 at 5:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Indexes:
foo_pkey PRIMARY KEY, btree (f1), tablespace ts1
foo_f2_exclusion btree (f2), tablespace ts1
foo_f3_exclusion btree (f3) DEFERRABLE INITIALLY DEFERRED
Exclusion constraints:
foo_f2_exclusion EXCLUDE
Greg Stark gsst...@mit.edu writes:
There is a third option -- print PRIMARY keys twice, once as a btree
index and again as a constraint where it says somehting like USING
index foo_pkey
No, that's exactly what I hate about the current behavior for exclusion
constraints, and I'd like it even
On Thu, 2010-03-11 at 00:29 -0500, Tom Lane wrote:
Patch changes:
Indexes:
foo_pkey PRIMARY KEY, btree (f1), tablespace ts1
foo_f2_exclusion btree (f2), tablespace ts1
foo_f3_exclusion btree (f3) DEFERRABLE INITIALLY DEFERRED
Exclusion constraints:
foo_f2_exclusion
Awhile back I wrote:
* I'm not too satisfied with the behavior of psql's \d:
regression=# create table foo (f1 int primary key using index tablespace ts1,
regression(# f2 int, EXCLUDE USING btree (f2 WITH =) using index tablespace
ts1,
regression(# f3 int, EXCLUDE USING btree (f3 WITH =)
On Mon, 2009-12-07 at 00:26 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
[ exclusion constraint patch ]
Applied after quite a lot of editorialization. For future reference,
here is a summary of what I did:
Thank you for the suggestions, and the other constructive criticism
Jeff Davis pg...@j-davis.com writes:
[ exclusion constraints patch ]
Still working on this patch. I ran into something I didn't like at all:
+ if (newrel != NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+
On Sun, 2009-12-06 at 10:46 -0500, Tom Lane wrote:
This would be bad enough if the restriction were what the message
alleges, ie, you can't write an ALTER TABLE that both rewrites the heap
and adds an exclusion constraint. However, actually the error also
occurs if you issue a rewriting ALTER
Jeff Davis pg...@j-davis.com writes:
Aha -- I think I see the problem you're having: if you try to rewrite
one of the columns contained in the exclusion constraint, you get that
error:
It fails for me regardless of which column is actually modified.
It could be this is a consequence of other
On Sun, 2009-12-06 at 14:06 -0500, Tom Lane wrote:
It fails for me regardless of which column is actually modified.
It could be this is a consequence of other changes I've been making,
but given the way ALTER TABLE works it's hard to see why the specific
column being modified would matter.
Jeff Davis pg...@j-davis.com writes:
... I'll look into doing it as you suggest.
I'm already working with a pretty-heavily-editorialized version.
Don't worry about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Jeff Davis pg...@j-davis.com writes:
[ exclusion constraint patch ]
Applied after quite a lot of editorialization. For future reference,
here is a summary of what I did:
* Reworded and renamed stuff to try to be consistent about calling these
things exclusion constraints. The original code
On Fri, Dec 04, 2009 at 11:35:52AM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. �I thought the
consensus
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
was to refer to them as just exclusion constraints? I'm not
On Fri, 2009-12-04 at 11:35 -0500, Tom Lane wrote:
Unless there's loud squawks I'm going to exercise committer's
prerogative and make all the docs and messages just say exclusion
constraint.
Sounds fine to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
On Dec 4, 2009, at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-12-01 at 23:19 -0500, Robert Haas wrote:
For parity with unique constraints, I think that the message:
operator exclusion constraint violation detected: %s
should be changed to:
conflicting key value violates operator exclusion
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
was to refer to them as just exclusion constraints? I'm not seeing
that the word operator really adds anything.
I assume you're referring to the name used in documentation
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
was to refer to them as just exclusion constraints? I'm not seeing
that the word operator really adds
On Dec 3, 2009, at 6:26 PM, Robert Haas wrote:
Yeah, I don't remember any such consensus either, but it's not a dumb
name. I have been idly wondering throughout this process whether we
should try to pick a name that conveys the fact that these constraints
are inextricably tied to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Dec 03, 2009 at 08:38:06PM -0800, David E. Wheeler wrote:
[...]
Whatever constraints? Operator Whatevers? WhatEVERs? I like it.
drigting serioulsy off-topic: there's precedent for that in the most
venerable piece of free software; TeX has
On Wed, Dec 2, 2009 at 12:18 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2009-12-01 at 23:19 -0500, Robert Haas wrote:
For parity with unique constraints, I think that the message:
operator exclusion constraint violation detected: %s
should be changed to:
conflicting key value violates
On Fri, Nov 27, 2009 at 10:18 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-11-26 at 01:33 -0800, Jeff Davis wrote:
Remaining issues:
* represent operator IDs in catalog, rather than strategy numbers
Done, attached.
* if someone thinks it's an issue, support search strategies that
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, I applied it. The only significant thing I changed was that I
did not inline the index_elem because it made it fairly hard to read.
Instead, I renamed it exclude_elem to make it a little more
meaningful, which I
On Thu, 2009-11-26 at 16:31 -0500, Robert Haas wrote:
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, I applied it. The only significant thing I changed was that I
did not inline the index_elem because it made it fairly hard to read.
Instead, I renamed it
On Wed, Nov 25, 2009 at 3:23 AM, Jeff Davis pg...@j-davis.com wrote:
I was thinking maybe you call BuildIndexValueDescription twice and
make the error message say something like output of first call
conflicts with output of second call.
Do you really think that's a better error message, or
On Wed, 2009-11-25 at 09:02 -0500, Robert Haas wrote:
I disagree wholeheartedly. :-) My ideal error message is something like:
DETAIL: (a, b, c)=(1, 2, 3) conflicts with (a, b, c)=(4, 5, 6)
In particular, I think it's very important that we only emit the
columns which are part of the
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-11-25 at 09:02 -0500, Robert Haas wrote:
I disagree wholeheartedly. :-) My ideal error message is something like:
DETAIL: (a, b, c)=(1, 2, 3) conflicts with (a, b, c)=(4, 5, 6)
Ok, fair enough. But how do you feel about:
(a: 1, b: 2, c:
On Wed, 2009-11-25 at 15:59 -0800, Jeff Davis wrote:
My operator-class-fu is insufficient to render judgment on this point.
I think the thing to do is look at a bunch of non-built-in opclasses
and check for POLA violations.
Ok, I'll consider this more.
In cases where the operator class
On Fri, Nov 20, 2009 at 01:36:59PM +0900, Josh Berkus wrote:
RObert,
I guess I'm going to have to vote -1 on this proposal. I code see
inventing a pgsql-specific SQLSTATE value for exclusion constraints,
since they will be a pgsql-specific extension, but reusing the unique
key
On sön, 2009-11-22 at 16:03 -0800, David Fetter wrote:
What, if anything, does the standard have to say about violations of
ASSERTIONs? I know these aren't ASSERTIONs, but they much more
closely resemble them than they do UNIQUE constraints.
An assertion is by definition a constraint that is
On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis pg...@j-davis.com wrote:
I'm in Tokyo right now, so please excuse my abbreviated reply.
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant
On Wed, Nov 18, 2009 at 9:21 AM, Josh Berkus j...@agliodbs.com wrote:
All,
FWIW, I'm doing a redesign of a client's production web application
right now. I was able, by combining OEC and the Period type from
pgfoundry, to make a set of constraints for declaratively asserting in a
sports
RObert,
I guess I'm going to have to vote -1 on this proposal. I code see
inventing a pgsql-specific SQLSTATE value for exclusion constraints,
since they will be a pgsql-specific extension, but reusing the unique
key violation value seems misleading. I admit it may help in a
limited number
I'm in Tokyo right now, so please excuse my abbreviated reply.
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves?
At constraint definition
Robert Haas robertmh...@gmail.com writes:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves? It seems like this could lead to surprising behavior if
the user modifies the definition of the
All,
FWIW, I'm doing a redesign of a client's production web application
right now. I was able, by combining OEC and the Period type from
pgfoundry, to make a set of constraints for declaratively asserting in a
sports database:
That the same player couldn't belong to two different teams at the
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis pg...@j-davis.com wrote:
New patches attached.
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves? It seems like this could lead to surprising behavior if
On Nov 13, 2009, at 8:39 PM, Robert Haas wrote:
alter table foo add constraint bar exclude (a check with =, b check with =);
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the CHECK is strictly necessary there,
since the WITH
David E. Wheeler da...@kineticode.com writes:
On Nov 13, 2009, at 8:39 PM, Robert Haas wrote:
alter table foo add constraint bar exclude (a check with =, b check with =);
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the
On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the CHECK is strictly necessary there,
since the WITH seems adequate, and there was some discussion before about
the CHECK keyword
On Sat, Nov 14, 2009 at 12:11 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
I've been meaning to comment on this syntax one more time; apologies for
the bike-shedding. But I'm wondering if the CHECK is strictly necessary
there, since the WITH
Robert Haas robertmh...@gmail.com writes:
I haven't thought about this too deeply, but could we allow the with
= part to be optional? And would it be a good idea?
I don't think so. We generally do not believe in defaulting operators
based on name. If there were a way to select the standard
On Fri, 2009-11-13 at 23:39 -0500, Robert Haas wrote:
[ reviewing ]
Thank you for the comments so far.
In index_create(), the elog() where relopxconstraints 0 should just
complain about the value being negative, I think, rather than listing
the value. If you just say the value is -3, it
2009/11/15 Jeff Davis pg...@j-davis.com:
I know the error conventions are documented somewhere, but I completely
forgot where. Can you please point me to the right place? I thought most
error messages were supposed to be lower case, and detail messages were
supposed to read like sentences.
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis pg...@j-davis.com wrote:
Hopefully the user never sees that message -- it's almost an Assert.
PostgreSQL uses elog(ERROR,...) in many places that should be
unreachable, but might happen due to bugs in distant places or
corruption. I'm not sure the
On Sat, Nov 14, 2009 at 1:58 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis pg...@j-davis.com wrote:
Hopefully the user never sees that message -- it's almost an Assert.
PostgreSQL uses elog(ERROR,...) in many places that should be
unreachable, but might
On Sat, 2009-11-14 at 09:11 -0800, David E. Wheeler wrote:
On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
I had been manfully restraining myself from re-opening this discussion,
but yeah I was thinking the same thing. The original objection to using
just WITH was that it wasn't very clear
On Sat, 2009-11-14 at 14:36 -0500, Robert Haas wrote:
I guess my point wasn't that the message was likely to be exercised,
but rather that it isn't obvious that it's describing an error
condition at all. If you get this message:
relation whatever has relopxconstraints = -3
I pretty much
On Sat, Nov 14, 2009 at 2:39 PM, Jeff Davis pg...@j-davis.com wrote:
If you have a suggestion, I'll make the change. It doesn't sound too
urgent though, to me.
Yeah, probably not.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Mon, 2009-11-09 at 09:12 -0800, David E. Wheeler wrote:
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name operator-based exclusion
constraints, so we can also just use that name. Or,
On Sun, Nov 8, 2009 at 4:41 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2009-11-07 at 10:56 -0800, Jeff Davis wrote:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it seems
to impart more meaning than it
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name operator-based exclusion
constraints, so we can also just use that name. Or, just exclusion
constraints.
(exclusion constraints)++
David
--
On Mon, Nov 9, 2009 at 5:12 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name operator-based exclusion
constraints, so we can also just use
Greg Stark escribió:
Out of curiosity, is this feature at all similar to SQL assertions?
What would we be missing to turn this into them?
I see no relationship to assertions. Those are not tied to any
particular table, and are defined with any random expression you care to
think of.
--
Tom Lane escribió:
Andrew Dunstan and...@dunslane.net writes:
This is a pretty good short explanation of how to deal with shift/reduce
problems in bison. With your permission I'm going to copy it to the Wiki
If you like, but I think the part about figuring out which production
is the
On Mon, 2009-11-09 at 18:03 +, Greg Stark wrote:
Out of curiosity, is this feature at all similar to SQL assertions?
What would we be missing to turn this into them?
I addressed that here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00049.php
The exclusion constraint mechanism
On Sun, 2009-11-08 at 13:41 -0800, Jeff Davis wrote:
On Sat, 2009-11-07 at 10:56 -0800, Jeff Davis wrote:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it seems
to impart more meaning than it actually can.
On Sun, 2009-11-08 at 22:03 +, Simon Riggs wrote:
Don't think that name is very useful either... sounds like you want to
exclude operators, which is why I got lost in the first place. I'd call
them generic exclusion constraints or user-defined exclusion
constraints. Sorry for this.
Either
On Fri, 2009-11-06 at 21:23 -0500, Tom Lane wrote:
Or maybe forget about it and go to EXCLUDE or EXCLUDING?
I left it as EXCLUSION for now. EXCLUDING USING ... and EXCLUSIVE
USING ... both sound a little awkward to me. Either could be improved
by moving the USING clause around, but that just
Jeff Davis pg...@j-davis.com writes:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it seems
to impart more meaning than it actually can. I doubt anyone would
actually be more confused in practice, though. If
On Sat, Nov 7, 2009 at 1:56 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2009-11-06 at 21:23 -0500, Tom Lane wrote:
Or maybe forget about it and go to EXCLUDE or EXCLUDING?
I left it as EXCLUSION for now. EXCLUDING USING ... and EXCLUSIVE
USING ... both sound a little awkward to me. Either
On Nov 7, 2009, at 11:08 AM, Tom Lane wrote:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it
seems
to impart more meaning than it actually can. I doubt anyone would
actually be more confused in practice,
On Sat, 2009-11-07 at 14:11 -0500, Robert Haas wrote:
Honestly, I'd probably be in favor of breaking the virtual tie in
favor of whichever word is already a keyword
The ones that are already keywords are EXCLUSIVE and EXCLUDING, which
are also the least desirable, so that rule doesn't work as a
Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-11-07 at 14:11 -0500, Robert Haas wrote:
Honestly, I'd probably be in favor of breaking the virtual tie in
favor of whichever word is already a keyword
The ones that are already keywords are EXCLUSIVE and EXCLUDING, which
are also the least
On Nov 5, 2009, at 11:09 AM, Jeff Davis wrote:
I think EXCLUDING conflicts with the EXCLUDING in LIKE. Also, it
becomes
a little more difficult to place the access method clause, because
EXCLUDING USING gist doesn't sound great.
Well that's clearly a verb. So perhaps EXCLUDE USING
gist
On Thu, 2009-11-05 at 10:30 -0800, David E. Wheeler wrote:
But that doesn't read as well to my eye as:
EXCLUDE (...) BY ...
I think EXCLUDE might be a little *too* specific. It sounds like
whatever is on the right hand side will be excluded, but that's not
really what happens.
EXCLUSION
On Thu, 2009-11-05 at 11:16 -0800, David E. Wheeler wrote:
Well that's clearly a verb. So perhaps EXCLUDE USING
gist (EXCLUDING USING gist is a little weirder).
That's not bad.
As I just said in my other email, I think the word EXCLUDE is a little
bit too specific, but the other ideas out
On Thu, 2009-11-05 at 09:56 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Ooh, that's kind of neat. But I think you'd need EXCLUSIVE (a, b) BY
(=, =), since it could equally well be EXCLUSIVE (a, b) BY (=, ).
Yeah, we definitely want some parentheses delimiting the
On Mon, 2009-11-02 at 18:28 +, Simon Riggs wrote:
I like the NOT here because CHECK NOT = seems to convey pretty
clearly what it is you are checking for. Because NOT is reserved and
can't appear as a connective, I think that this approach might allow
a non-reserved leading word, thus
Jeff Davis pg...@j-davis.com writes:
I'm not excited about using NOT, because I think it has a hint of a
double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
2009/11/3 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com writes:
I'm not excited about using NOT, because I think it has a hint of a
double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
Is this really a generalized uniqueness
On Tue, Nov 3, 2009 at 5:05 PM, Jeff Davis pg...@j-davis.com wrote:
We already have some reasonable agreement around EXCLUSION ... CHECK
WITH. We should stick with the current syntax unless there's a good
consensus around some other specific proposal.
Yeah. I don't like the inflexibility of
On Tue, 2009-11-03 at 21:31 +, Dean Rasheed wrote:
Is this really a generalized uniqueness constraint, extended to
support operators other than = ?
That has been discussed in the past:
http://archives.postgresql.org/message-id/1253119552.24770.203.ca...@jdavis
On Sun, 2009-11-01 at 22:42 +, Simon Riggs wrote:
The current patch writes the syntax like this
EXCLUSION USING gist (c CHECK WITH )
makes it look like a table constraint, yet it clearly refers to a
single
column. That looks very clumsy to read, to my eyes.
I think the word CHECK
On Sun, 2009-11-01 at 18:07 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The syntax be easier to read if it was stated as a comparison
e.g. in the circle example
CHECK ( NOT (NEW.c c)) USING GIST
I don't think this is a good idea at all. NEW is a nonstandard
On Mon, 2009-11-02 at 07:38 +, Simon Riggs wrote:
It bothers me that we would have completely separate syntax for this
feature as opposed to normal SQL. It also doesn't make it easy to
interpret from the business statement to the implementation. Notice that
the , above means AND.
Yes, in
On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
I think the word CHECK should be avoided completely in this syntax, to
avoid confusion with CHECK constraints.
This is an easy change. I don't have a strong opinion, so the only thing
I can think to do is ask for a vote.
Do you have a
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
I think the word CHECK should be avoided completely in this syntax, to
avoid confusion with CHECK constraints.
This is an easy change. I don't have a strong opinion, so the only thing
I can think
On Mon, 2009-11-02 at 13:12 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
I think the word CHECK should be avoided completely in this syntax, to
avoid confusion with CHECK constraints.
This is an easy change. I
On Sun, 2009-11-01 at 10:53 -0800, Jeff Davis wrote:
New patch attached.
After reading the docs in the patch I don't believe you're going to all
this trouble to ensure two circles don't overlap. Can you give some
better examples of what you're trying to achieve and why anyone else
would care?
After reading the docs in the patch I don't believe you're going to all
this trouble to ensure two circles don't overlap. Can you give some
better examples of what you're trying to achieve and why anyone else
would care? (I'm busy, so are others).
Non overlapping time intervals is one use
Simon Riggs si...@2ndquadrant.com writes:
The syntax be easier to read if it was stated as a comparison
e.g. in the circle example
CHECK ( NOT (NEW.c c)) USING GIST
I don't think this is a good idea at all. NEW is a nonstandard
Postgres-ism, and introducing it into this syntax doesn't seem
On Sun, 2009-11-01 at 22:42 +, Simon Riggs wrote:
After reading the docs in the patch I don't believe you're going to all
this trouble to ensure two circles don't overlap. Can you give some
better examples of what you're trying to achieve and why anyone else
would care? (I'm busy, so are
On Sun, 2009-11-01 at 15:42 -0800, Jeff Davis wrote:
Most of the time, there will be two columns like:
EXCLUSION(room_number CHECK WITH =, during CHECK WITH )
Now that's a great example.
Looks like the classic don't allow the same room to be booked more than
once at the same time.
It
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 Sun, Sep 27, 2009 at 11:31 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2009-09-27 at 22:40 -0400, Robert Haas wrote:
Apparently, CommitFest
no longer means a time when people put aside their own patches to
review those of others; it seems now to mean a time when 87% of the
patch
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, Sep 27, 2009 at 5:47 PM, Jeff Davis pg...@j-davis.com wrote:
Attached is a new patch. I ran it through filterdiff, but in case that
didn't work for some reason, I attached a gzipped version of the
original unified diff produced by git.
* Changed underlying algorithm to match Tom's
On Sun, 2009-09-27 at 21:38 -0400, Robert Haas wrote:
In that case, I think we should target this for the next CommitFest.
Especially given the number and complexity of the patches remaining
for this CommitFest, I feel very uncomfortable with the idea of
waiting another week for a new patch
On Sun, Sep 27, 2009 at 10:13 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2009-09-27 at 21:38 -0400, Robert Haas wrote:
In that case, I think we should target this for the next CommitFest.
Especially given the number and complexity of the patches remaining
for this CommitFest, I feel very
On Sun, 2009-09-27 at 22:40 -0400, Robert Haas wrote:
Apparently, CommitFest
no longer means a time when people put aside their own patches to
review those of others; it seems now to mean a time when 87% of the
patch authors either continue development or ignore the CommitFest
completely.
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
1 - 100 of 115 matches
Mail list logo
