Re: 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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)fetter(dot)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(at)fetter(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)fetter(dot)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(at)2ndQuadrant(dot)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(at)fetter(dot)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(at)2ndQuadrant(dot)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(at)2ndQuadrant(dot)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(at)commandprompt(dot)com> wrote:
> Tom Lane wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)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