On 12/12/14, 7:16 PM, Tom Lane wrote:
Jim Nasby writes:
I'd say that array_eq (and probably _cmp) just needs to be taught to fall back
to what oper() does, but this part of the commit message gives me pause:
"Change the operator search algorithms to look for appropriate btree or hash index
Jim Nasby writes:
> I'd say that array_eq (and probably _cmp) just needs to be taught to fall
> back to what oper() does, but this part of the commit message gives me pause:
> "Change the operator search algorithms to look for appropriate btree or hash
> index opclasses, instead of assuming ope
On 12/9/14, 5:06 PM, Jim Nasby wrote:
On 12/9/14, 4:30 PM, Tom Lane wrote:
Jim Nasby writes:
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar
On 12/9/14, 4:30 PM, Tom Lane wrote:
Jim Nasby writes:
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays.
Adding operators would be an
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! ht
Jim Nasby writes:
> On 12/9/14, 4:19 PM, Jim Nasby wrote:
>> Is there any particular reason we don't allow comparing char and varchar
>> arrays? If not I'll submit a patch.
> We're also missing operators on text and varchar arrays.
Adding operators would be an incorrect fix.
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Tue, Sep 3, 2013 at 9:13 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
>>> While playing around with Andres's trick, I noticed that it works but
>>> will not match against operators taking "any" although those will
>>> match with explicit sc
Andres Freund writes:
> On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
>> While playing around with Andres's trick, I noticed that it works but
>> will not match against operators taking "any" although those will
>> match with explicit schema declaration (FWICT it goes through the
>> search_p
On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
> While playing around with Andres's trick, I noticed that it works but
> will not match against operators taking "any" although those will
> match with explicit schema declaration (FWICT it goes through the
> search_path trying to explicitly matc
On Fri, Aug 30, 2013 at 5:48 PM, Andres Freund wrote:
> Hi,
>
> On 2013-08-30 17:35:04 -0500, Merlin Moncure wrote:
>> "When a schema-qualified operator name is used in the OPERATOR syntax,
>> as for example in:
>> SELECT 3 OPERATOR(pg_catalog.+) 4;
>> the OPERATOR construct is taken to have the d
Hi,
On 2013-08-30 17:35:04 -0500, Merlin Moncure wrote:
> "When a schema-qualified operator name is used in the OPERATOR syntax,
> as for example in:
> SELECT 3 OPERATOR(pg_catalog.+) 4;
> the OPERATOR construct is taken to have the default precedence shown
> in Table 4-2 for "any other" operator.
Merlin Moncure writes:
> The operator precedence rules seem hard wired to not be able to be
> worked around, not matter what.
That's right. In the first place, bison is incapable of doing anything
other than hard-wired operator precedence. In the second, if we did
try to allow catalog-driven pr
Hackers,
The operator precedence rules seem hard wired to not be able to be
worked around, not matter what. The pain point for me has always been
the division operator -- once in a while I end up in a situation where
I want to override it so that it wraps the divisor with NULLIF. There
is no way
Robert Haas writes:
> a separate ALTER OPERATOR < COMMUTATOR > statement (or something of
> the sort) that pg_dump can emit as a separate item. Even a NOTICE in
I like that capability, but it's not helping us in the backward
compatibility section where we will still read commutator declarations
Robert Haas writes:
> On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane wrote:
>> I was thinking a NOTICE at most. If it's a WARNING then restoring
>> perfectly valid pg_dump files will result in lots of scary-looking
>> chatter. You could make an argument for printing nothing at all,
>> but that woul
On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane wrote:
> Brendan Jurd writes:
>> On 20 December 2012 11:51, Tom Lane wrote:
>>> While reconsidering the various not-too-satisfactory fixes we thought of
>>> back then, I had a sudden thought. Instead of having a COMMUTATOR or
>>> NEGATOR forward refere
Brendan Jurd writes:
> On 20 December 2012 11:51, Tom Lane wrote:
>> While reconsidering the various not-too-satisfactory fixes we thought of
>> back then, I had a sudden thought. Instead of having a COMMUTATOR or
>> NEGATOR forward reference create a "shell" operator and link to it,
>> why not
On 20 December 2012 11:51, Tom Lane wrote:
>
> While reconsidering the various not-too-satisfactory fixes we thought of
> back then, I had a sudden thought. Instead of having a COMMUTATOR or
> NEGATOR forward reference create a "shell" operator and link to it,
> why not simply *ignore* such refer
Bug #7758 seems to be a rediscovery of the behavior that Itagaki-san
complained of a couple years ago:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02035.php
While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought. Instead of having a
On 09/07/2011 12:10 PM, Tom Lane wrote:
> I guess if it contains no opclasses and no operators either, this code
> won't dump it, but isn't it rather useless in such a case?
Yes, I think it's useless, like a book cover without the contents, but
ISTM it should still be dumped (perhaps someone start
Joe Abbate writes:
> If a basic operator family is created, e.g.,
> create operator family of1 using btree;
> shouldn't pg_dump include this in its output? If not, why?
Quoting from the pg_dump source code:
* We want to dump the opfamily only if (1) it contains "loose" operators
* or
Hi,
If a basic operator family is created, e.g.,
create operator family of1 using btree;
shouldn't pg_dump include this in its output? If not, why?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Alexey,
On Fri, Jun 10, 2011 at 05:46:42PM +0300, Alexey Klyukin wrote:
> Providing my thoughts on the 'mundane' question first.
I was actually referring to this paragraph:
The standing code handled index/constraint dependencies of changing columns by
extracting the SQL definition using pg_g
Noah,
Providing my thoughts on the 'mundane' question first.
On Tue, May 24, 2011 at 1:40 PM, Noah Misch wrote:
>
> I also had a more mundane design question in the second paragraph of [2]. It
> can probably wait for the review of the next version of the patch. However,
> given that it affects
On Tue, May 24, 2011 at 10:10:34AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
> > binary coercion cast without rewriting the table or unrelated indexes. It
> > will always rewrite any indexes and recheck any foreign k
Noah Misch writes:
> PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
> binary coercion cast without rewriting the table or unrelated indexes. It
> will always rewrite any indexes and recheck any foreign key constraints that
> depend on a changing column. This is unnece
PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
binary coercion cast without rewriting the table or unrelated indexes. It
will always rewrite any indexes and recheck any foreign key constraints that
depend on a changing column. This is unnecessary for 100% of core binar
Am 26.04.2011 17:37, schrieb Tom Lane:
> =?ISO-8859-1?Q?Yves_Wei=DFig?=
> writes:
>> Am 26.04.2011 14:28, schrieb Robert Haas:
>>> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
>>> wrote:
CREATE OPERATOR CLASS abstime_ops
DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
OPE
=?ISO-8859-1?Q?Yves_Wei=DFig?= writes:
> Am 26.04.2011 14:28, schrieb Robert Haas:
>> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
>> wrote:
>>> CREATE OPERATOR CLASS abstime_ops
>>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>>> OPERATOR 1 = (abstime,abstime),
>>> FUNCTION 1 hashin
Am 26.04.2011 14:28, schrieb Robert Haas:
> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
> wrote:
>> CREATE OPERATOR CLASS abstime_ops
>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>> OPERATOR 1 = (abstime,abstime),
>> FUNCTION 1 hashint4(abstime,abstime);
>>
>> it yields: ERROR:
On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
wrote:
> CREATE OPERATOR CLASS abstime_ops
> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
> OPERATOR 1 = (abstime,abstime),
> FUNCTION 1 hashint4(abstime,abstime);
>
> it yields: ERROR: function hashint4(abstime, abstime) does not exist
Am 26.04.2011 01:15, schrieb Tom Lane:
> =?ISO-8859-15?Q?Yves_Wei=DFig?=
> writes:
>> But anyway I am having trouble creating an operator class:
>
>> CREATE OPERATOR CLASS abstime_ops
>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>> OPERATOR 1 = ,
>> FUNCTION 1 abstimeeq(abstime
=?ISO-8859-15?Q?Yves_Wei=DFig?= writes:
> But anyway I am having trouble creating an operator class:
> CREATE OPERATOR CLASS abstime_ops
> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
> OPERATOR 1 = ,
> FUNCTION 1 abstimeeq(abstime,abstime);
> yields: ERROR: invalid procedure numb
Am 24.04.2011 23:33, schrieb Tom Lane:
> =?ISO-8859-15?Q?Yves_Wei=DFig?=
> writes:
>> again index access methods, can somebody shed some light into operator
>> classes for indexes? The documentation is an entry point, but after
>> reading I still don't have a clue how exactly they are used and cr
=?ISO-8859-15?Q?Yves_Wei=DFig?= writes:
> again index access methods, can somebody shed some light into operator
> classes for indexes? The documentation is an entry point, but after
> reading I still don't have a clue how exactly they are used and created?
> Perhaps somebody with great knowledge
Hi,
again index access methods, can somebody shed some light into operator
classes for indexes? The documentation is an entry point, but after
reading I still don't have a clue how exactly they are used and created?
Perhaps somebody with great knowledge can supply an 101 on opeartor
classes? Becau
Itagaki Takahiro writes:
> On Wed, Sep 29, 2010 at 11:56 PM, Tom Lane wrote:
>> I'm not sure that fixing this case is worth the amount of work it'd
>> take. How often do you drop just one member of a commutator pair?
> I found the issue when an user tries to write a "safe" installer
> script un
On Wed, Sep 29, 2010 at 11:56 PM, Tom Lane wrote:
> I'm not sure that fixing this case is worth the amount of work it'd
> take. How often do you drop just one member of a commutator pair?
I found the issue when an user tries to write a "safe" installer
script under "DROP before CREATE" coding ru
Alvaro Herrera writes:
> Excerpts from Itagaki Takahiro's message of mié sep 29 03:56:33 -0400 2010:
>> When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
>> pg_dump generates an invalid SQL command for the operators depending on
>> the dropped one. Is it an unavoidable re
Excerpts from Itagaki Takahiro's message of mié sep 29 03:56:33 -0400 2010:
> When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
> pg_dump generates an invalid SQL command for the operators depending on
> the dropped one. Is it an unavoidable restriction?
Maybe we need a pg
When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
pg_dump generates an invalid SQL command for the operators depending on
the dropped one. Is it an unavoidable restriction?
CREATE OPERATOR <<< (
PROCEDURE = text_lt, LEFTARG = text, RIGHTARG = text, COMMUTATOR = >>>
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
1 - 100 of 240 matches
Mail list logo
