Thread: Exclusion Constraint vs. Constraint Exclusion
Folks, We have a very unfortunate naming situation with Jeff Davis's new feature, namely the shorter name, which is one permutation away from an existing and entirely unrelated feature: Constraint Exclusion, which has to do with queries over partitioned tables and like entities. Renaming it, which I believe we should do Really Soon(TM), to Operator [Exclusion] Constraints would fix this problem. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter wrote: > Folks, > > We have a very unfortunate naming situation with Jeff Davis's new > feature, namely the shorter name, which is one permutation away from > an existing and entirely unrelated feature: Constraint Exclusion, > which has to do with queries over partitioned tables and like > entities. > > Renaming it, which I believe we should do Really Soon(TM), to Operator > [Exclusion] Constraints would fix this problem. > > Cheers, > David. +1 I thought I was just too dumb to follow the conversation.
David Fetter <david@fetter.org> writes:
> We have a very unfortunate naming situation with Jeff Davis's new
> feature, namely the shorter name, which is one permutation away from
> an existing and entirely unrelated feature: Constraint Exclusion,
> which has to do with queries over partitioned tables and like
> entities.
> Renaming it, which I believe we should do Really Soon(TM), to Operator
> [Exclusion] Constraints would fix this problem.
Too late. I just spent about two days making that patch follow the
"exclusion constraints" naming, and I'm not undoing that work.
regards, tom lane
On Mon, Dec 07, 2009 at 07:11:56PM -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > We have a very unfortunate naming situation with Jeff Davis's new > > feature, namely the shorter name, which is one permutation away > > from an existing and entirely unrelated feature: Constraint > > Exclusion, which has to do with queries over partitioned tables > > and like entities. > > > Renaming it, which I believe we should do Really Soon(TM), to > > Operator [Exclusion] Constraints would fix this problem. > > Too late. I just spent about two days making that patch follow the > "exclusion constraints" naming, and I'm not undoing that work. It's not work you personally would have to do, and the confusion we've already bought with this naming scheme is already evident. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Mon, 2009-12-07 at 13:53 -0800, David Fetter wrote: > We have a very unfortunate naming situation with Jeff Davis's new > feature, namely the shorter name, which is one permutation away from > an existing and entirely unrelated feature: Constraint Exclusion, > which has to do with queries over partitioned tables and like > entities. I agree, though with partitioning patch about to become reality the name confusion will be less noticeable. > Renaming it, which I believe we should do Really Soon(TM), to Operator > [Exclusion] Constraints would fix this problem. If we do need to do this, perhaps we should change the older parameter to be partition_exclusion. -- Simon Riggs www.2ndQuadrant.com
David Fetter <david@fetter.org> writes:
> It's not work you personally would have to do, and the confusion we've
> already bought with this naming scheme is already evident.
What confusion? The only person complaining is you.
regards, tom lane
Simon Riggs <simon@2ndQuadrant.com> writes:
> If we do need to do this, perhaps we should change the older parameter
> to be partition_exclusion.
Yeah, if we do want to do something about this then changing the name of
the existing GUC would be a lot less work. However, partition_exclusion
seems to imply that it *only* applies to partitioned tables, which is
not the case...
regards, tom lane
On 12/7/09 5:17 PM, Tom Lane wrote: > David Fetter <david@fetter.org> writes: >> It's not work you personally would have to do, and the confusion we've >> already bought with this naming scheme is already evident. > > What confusion? The only person complaining is you. Actually, he has a very good point; we're going to get a *lot* of confusion from the users on this one. I just wish I'd noticed the issue before. --Josh Berkus
On Mon, 07 Dec 2009 20:20:45 -0500 Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > If we do need to do this, perhaps we should change the older parameter > > to be partition_exclusion. > > Yeah, if we do want to do something about this then changing the name of > the existing GUC would be a lot less work. However, partition_exclusion > seems to imply that it *only* applies to partitioned tables, which is > not the case... It is less coding work - but it will for sure confuse the users. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project
Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > If we do need to do this, perhaps we should change the older parameter
> > to be partition_exclusion.
>
> Yeah, if we do want to do something about this then changing the name of
> the existing GUC would be a lot less work. However, partition_exclusion
> seems to imply that it *only* applies to partitioned tables, which is
> not the case...
Perhaps
table_exclusion = {on, off, partition}
Of course, constraint_exclusion should continue to work as a synonym for
backwards compatibility, but it wouldn't be documented.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, 2009-12-07 at 23:12 -0300, Alvaro Herrera wrote:
> Perhaps
> table_exclusion = {on, off, partition}
Sounds good to me.
> Of course, constraint_exclusion should continue to work as a synonym for
> backwards compatibility, but it wouldn't be documented.
+1.
Regards,Jeff Davis
On Mon, 2009-12-07 at 17:41 -0800, Josh Berkus wrote: > Actually, he has a very good point; we're going to get a *lot* of > confusion from the users on this one. I just wish I'd noticed the issue > before. The issue has been mentioned several times, but must have gotten lost among the other emails. I put one such mention on the commitfest page so that it wouldn't be lost, but I suppose it was anyway: http://archives.postgresql.org/message-id/1258227283.708.108.camel@jdavis Regards,Jeff Davis
On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Tom Lane wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>> > If we do need to do this, perhaps we should change the older parameter
>> > to be partition_exclusion.
>>
>> Yeah, if we do want to do something about this then changing the name of
>> the existing GUC would be a lot less work. However, partition_exclusion
>> seems to imply that it *only* applies to partitioned tables, which is
>> not the case...
>
> Perhaps
> table_exclusion = {on, off, partition}
>
> Of course, constraint_exclusion should continue to work as a synonym for
> backwards compatibility, but it wouldn't be documented.
This seems pretty horrible to me. I'm not sure whether the current
code supports excluding appendrel members that are not base tables,
but even if it doesn't it certainly might some day. Furthermore, the
term "constraint exclusion" is a well-established. We're not going to
reduce confusing by adding a new feature with a similar name and
simultaneously renaming the old feature to something different. If
we're going to rename anything, it should be the new feature, though
I'm not entirely convinced that's really necessary either.
...Robert