From: https://www.postgresql.org/docs/9.4/static/sql-createtable.html

"The access method must support amgettuple (see Chapter 55); at
present this means GIN cannot be used. Although it's allowed, there is
little point in using B-tree or hash indexes with an exclusion
constraint, because this does nothing that an ordinary unique
constraint doesn't do better. So in practice the access method will
always be GiST or SP-GiST."

This is misleading.  Hash indexes do not support unique constraints
directly, but do support them via the EXCLUDE syntax using "WITH =".
This is nice if you want a unique index on something that might
occasionally exceed 1/3 of 8kB (titin, I'm looking at you)

Trivial doc patch attached.

Cheers,

Jeff
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
new file mode 100644
index bf2ad64..77d46de
*** a/doc/src/sgml/ref/create_table.sgml
--- b/doc/src/sgml/ref/create_table.sgml
*************** CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY
*** 574,583 ****
        The access method must support <literal>amgettuple</> (see <xref
        linkend="indexam">); at present this means <acronym>GIN</>
        cannot be used.  Although it's allowed, there is little point in using
!       B-tree or hash indexes with an exclusion constraint, because this
        does nothing that an ordinary unique constraint doesn't do better.
!       So in practice the access method will always be <acronym>GiST</> or
!       <acronym>SP-GiST</>.
       </para>
  
       <para>
--- 574,583 ----
        The access method must support <literal>amgettuple</> (see <xref
        linkend="indexam">); at present this means <acronym>GIN</>
        cannot be used.  Although it's allowed, there is little point in using
!       B-tree indexes with an exclusion constraint, because this
        does nothing that an ordinary unique constraint doesn't do better.
!       So in practice the access method will always be <acronym>GiST</>,
!       <acronym>SP-GiST</>, or hash.
       </para>
  
       <para>
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to