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:
> >
Greg Stark 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 less for more
On Thu, Mar 11, 2010 at 5:29 AM, Tom Lane 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" EXC
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 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
during devel
Jeff Davis 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 and docs bore qui
Jeff Davis 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 changes to your subscr
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 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 changes I've bee
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 AL
Jeff Davis 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 Fri, Dec 04, 2009 at 11:35:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis 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 jus
On Dec 4, 2009, at 11:35 AM, Tom Lane wrote:
Robert Haas writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis 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
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 (pgsql-ha
Robert Haas writes:
> On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis 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 "operat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Dec 03, 2009 at 08:38:06PM -0800, David E. Wheeler wrote:
[...]
> "Whatever constraints"? "Operator Whatevers"? "WhatEVER"s? I like it.
drigting serioulsy off-topic: there's precedent for that in the most
venerable piece of free software; Te
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 opcl
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis 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 anything.
>
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 documentat
Jeff Davis 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 constraint "
On Wed, Dec 2, 2009 at 12:18 AM, Jeff Davis 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 op
On Fri, Nov 27, 2009 at 10:18 PM, Jeff Davis 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
>> re
On Thu, 2009-11-26 at 16:31 -0500, Robert Haas wrote:
> On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis 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"
On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis 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 assume may have
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
Jeff Davis 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: 3)
> as
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 th
On Wed, Nov 25, 2009 at 3:23 AM, Jeff Davis wrote:
>> I was thinking maybe you call BuildIndexValueDescription twice and
>> make the error message say something like
>> conflicts with .
>
> Do you really think that's a better error message, or are you just
> trying to re-use similar code?
>
> Let
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 i
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
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 nu
On Wed, Nov 18, 2009 at 9:21 AM, Josh Berkus 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 database:
>
> T
On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis 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 operators instead
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 s
Robert Haas 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 operator class.
Wild gue
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 t
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis 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
the user modifies
On Sat, Nov 14, 2009 at 2:39 PM, Jeff Davis 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 subscription:
http://www
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 na
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 prett
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 cl
On Sat, Nov 14, 2009 at 1:58 PM, Greg Stark wrote:
> On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis 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
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis 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 exact convention
2009/11/15 Jeff Davis :
> 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.
http://www.postg
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, i
Robert Haas 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" exclusion
operato
On Sat, Nov 14, 2009 at 12:11 PM, David E. Wheeler 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 seems ad
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
"David E. Wheeler" 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 "CHECK" is strictl
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
On Sun, Nov 8, 2009 at 4:41 PM, 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 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 mechanis
Tom Lane escribió:
> Andrew Dunstan 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 problem seemed
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.
--
Alv
On Mon, Nov 9, 2009 at 5:12 PM, 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 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 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.
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 actuall
Jeff Davis 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 desirable, s
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
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, th
On Sat, Nov 7, 2009 at 1:56 PM, Jeff Davis 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 could b
Jeff Davis 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 a couple of pe
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
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 o
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.
EXCLUSI
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 09:56 -0500, Tom Lane wrote:
> Robert Haas 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 expression.
> EXC
2009/11/3 Tom Lane :
> Jeff Davis 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 constraint, extended to
suppo
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
http://archives.postgresql.o
On Tue, Nov 3, 2009 at 5:05 PM, Jeff Davis 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 the current synt
Jeff Davis 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 (pgsql-hackers@p
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
On Mon, 2009-11-02 at 13:12 -0500, Tom Lane wrote:
> Jeff Davis 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 hav
Jeff Davis 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 to do is as
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
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".
Y
On Sun, 2009-11-01 at 18:07 -0500, Tom Lane wrote:
> Simon Riggs 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,
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 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-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 ar
Simon Riggs 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 very
future-proo
> 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 us
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? (
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 11:31 PM, Jeff Davis 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 authors either
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, Sep 27, 2009 at 10:13 PM, Jeff Davis 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 uncomfortab
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 5:47 PM, Jeff Davis 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 suggestion: do
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_
1 - 100 of 113 matches
Mail list logo
