On Mon, Aug 2, 2010 at 2:39 AM, Jeff Davis <pg...@j-davis.com> wrote: > On Sun, 2010-08-01 at 21:57 -0400, Robert Haas wrote: >> On Fri, Jul 16, 2010 at 1:19 AM, Jeff Davis <pg...@j-davis.com> wrote: >> > Thank you for the review. >> > >> > On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote: >> >> (1) Exclusion constraints support for operators where "x <operator> x" >> >> is false (tiny patch) >> >> https://commitfest.postgresql.org/action/patch_view?id=307 >> >> (2) btree_gist support for searching on <> ("not equals") >> >> https://commitfest.postgresql.org/action/patch_view?id=308 >> >> >> >> Those patches should be committed at once because (2) requires (1) to work >> >> with EXCLUDE constraints. Also, (1) has no benefits without (2) because we >> >> have no use cases for <> as an index-able operator. Both patches are very >> >> simple and small, and worked as expected both "WHERE <>" and EXCLUDE >> >> constraints cases. >> > >> > It appears that Tom already committed (1). >> > >> >> I'd like to ask you to write additional documentation about btree_gist [1] >> >> that the module will be more useful when it is used with exclusion >> >> constraints together. Without documentation, no users find the usages. >> > >> > Good idea, new patch attached. >> >> It seems pretty odd to define a constant called >> BTNotEqualStrategyNumber in contrib/btree_gist. Shouldn't we either >> call this something else, or define it in access/skey.h? Considering >> that there seem to be some interesting gymnastics being done with >> BTMaxStrategyNumber, I'd vote for the former. Maybe just >> BtreeGistNotEqualStrategyNumber? > > Sounds good to me.
OK, committed that way. > At some point we may be interested to add this to BTree, as well. But we > can cross that bridge when we come to it. Yeah. I was also wondering if it would be worth adding some additional regression testing to contrib/btree_gist exercising this new functionality. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers