From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | PG10 Crash-safe and replicable Hash Indexes and UNIQUE |
Date: | 2017-05-19 15:34:08 |
Message-ID: | 6318fb86-0a64-61e7-e4e2-714db2b3407a@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
The item on hash indexes reminded me of an old comment from years
ago that I put in the code of the first custom PG datatype I ever
built at $work:
COMMENT ON OPERATOR CLASS puid_ops USING btree IS
'As puids are only identifiers, there is no obvious reason to define
ordering operators or support btree indexing. But for some curious
reason PostgreSQL 8.4 does not allow a hash index to support UNIQUE
constraints (this may be because, per the manual, hash index "operations
are not presently WAL-logged" so it could be risky to base constraints
on them). Therefore, the whole set of ordering operators must be
implemented to provide an operator class for the btree index method.';
Was my guess about the reason right? Does this PG10 announcement
also mean it will be possible to use UNIQUE constraints with some
pure-identifier, no-natural-ordering type that supports only hashing?
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-19 15:41:21 | Re: PG10 Crash-safe and replicable Hash Indexes and UNIQUE |
Previous Message | Tom Lane | 2017-05-19 15:22:54 | Re: Preliminary results for proposed new pgindent implementation |