small exclusion constraints patch
in [PgSql]
|
Prev: unnailing shared relations (was Re: global temporary tables)
Next: [HACKERS] (9.1) btree_gist support for searching on "not equals"
From: Tom Lane on 21 May 2010 15:24 Jeff Davis <pgsql(a)j-davis.com> writes: > Currently, the check for exclusion constraints performs a sanity check > that's slightly too strict -- it assumes that a tuple will conflict with > itself. That is not always the case: the operator might be "<>", in > which case it's perfectly valid for the search for conflicts to not find > itself. > This patch simply removes that sanity check, and leaves a comment in > place. I'm a bit uncomfortable with removing the sanity check; it seems like a good thing to have, especially since this code hasn't even made it out of beta yet. AFAIK the "<>" case is purely hypothetical, because we have no index opclasses supporting such an operator, no? How about just documenting that we'd need to remove the sanity check if we ever did add support for such a case? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 28 May 2010 22:32 Tom Lane wrote: > Jeff Davis <pgsql(a)j-davis.com> writes: > > Currently, the check for exclusion constraints performs a sanity check > > that's slightly too strict -- it assumes that a tuple will conflict with > > itself. That is not always the case: the operator might be "<>", in > > which case it's perfectly valid for the search for conflicts to not find > > itself. > > > This patch simply removes that sanity check, and leaves a comment in > > place. > > I'm a bit uncomfortable with removing the sanity check; it seems like a > good thing to have, especially since this code hasn't even made it out > of beta yet. AFAIK the "<>" case is purely hypothetical, because we > have no index opclasses supporting such an operator, no? How about just > documenting that we'd need to remove the sanity check if we ever did add > support for such a case? Done, with attached, applied patch. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
From: Robert Haas on 29 May 2010 17:16 On Fri, May 28, 2010 at 10:32 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Tom Lane wrote: >> Jeff Davis <pgsql(a)j-davis.com> writes: >> > Currently, the check for exclusion constraints performs a sanity check >> > that's slightly too strict -- it assumes that a tuple will conflict with >> > itself. That is not always the case: the operator might be "<>", in >> > which case it's perfectly valid for the search for conflicts to not find >> > itself. >> >> > This patch simply removes that sanity check, and leaves a comment in >> > place. >> >> I'm a bit uncomfortable with removing the sanity check; it seems like a >> good thing to have, especially since this code hasn't even made it out >> of beta yet. AFAIK the "<>" case is purely hypothetical, because we >> have no index opclasses supporting such an operator, no? How about just >> documenting that we'd need to remove the sanity check if we ever did add >> support for such a case? > > Done, with attached, applied patch. The only disadvantage I see of just documenting this is that someone might write a user-defined index opclass that works like this, and they won't be able to use this until at least 9.1 (or at least, not without patching the source). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 May 2010 18:11 Robert Haas <robertmhaas(a)gmail.com> writes: > The only disadvantage I see of just documenting this is that someone > might write a user-defined index opclass that works like this, and > they won't be able to use this until at least 9.1 (or at least, not > without patching the source). I don't actually think that anyone's very likely to write a <>-like index operator. It's approximately useless to use an index for such a query. Or, to put it differently: if nobody's done that in the past twenty years, why is it likely to happen before 9.1? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 29 May 2010 19:32
On Sat, May 29, 2010 at 06:11:57PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > The only disadvantage I see of just documenting this is that > > someone might write a user-defined index opclass that works like > > this, and they won't be able to use this until at least 9.1 (or at > > least, not without patching the source). > > I don't actually think that anyone's very likely to write a <>-like > index operator. It's approximately useless to use an index for such > a query. > > Or, to put it differently: if nobody's done that in the past twenty > years, why is it likely to happen before 9.1? Because there's a fundamentally new way to use them now, namely with exclusion constraints :) Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |