I am reviewing the following patch:
http://archives.postgresql.org/message-id/8e2dbb700907071138y4ebe75cw81879aa513cf8...@mail.gmail.com
In order to provide useful feedback, I would like to reach a consensus
on a possible index AM API change to make it easier to support
deferrable constraints for index access methods that enforce the
constraints themselves.
I am trying to word this question carefully, because there is a lot of
context:
* Dean Rasheed is implementing deferrable unique constraints for BTree
(in the patch linked above)
* Kenneth Marshall has indicated that he would like to implement
unique hash indexes in a way similar to the current btree
implementation:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00812.php
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00834.php
* I have a patch up for review that implements more general
constraints that are enforced outside of AM-specific code, and
therefore do not require index AM changes to support deferrable
constraints:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php
The btree unique code is already a "serious failure of modularity":
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00427.php
So, assuming that we support all of these features together, we have two
options that I see:
1. Extend the index AM API in a manner similar to Dean's patch.
2. Try to come up with some workaround to avoid changing the AM API
I was originally leaning toward approach #2 because I saw btree as the
only index AM that needed it, so extending the API seemed a little
excessive. However, seeing as it's potentially useful for unique hash
indexes, too, I am now leaning toward approach #1.
Also, we don't have performance numbers for either my feature or a
unique constraint implemented inside the hash index AM, so we don't know
whether that's a big win to enforce the constraint in the AM-specific
code or not.
So, should we proceed assuming an index AM API change, or try to avoid
it? If we should change the AM API, is Dean's API change acceptable?
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
