[HACKERS] 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 da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
David Fetter da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
On Mon, Dec 07, 2009 at 07:11:56PM -0500, Tom Lane wrote: David Fetter da...@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 da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
David Fetter da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
On 12/7/09 5:17 PM, Tom Lane wrote: David Fetter da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
On Mon, 07 Dec 2009 20:20:45 -0500 Tom Lane wrote: Simon Riggs si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
Tom Lane wrote:
Simon Riggs si...@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 Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
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.ca...@jdavis Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion
On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Simon Riggs si...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
