| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hashable custom types |
| Date: | 2014-04-27 01:35:32 |
| Message-ID: | CAM-w4HOyQ9C4+aW24JAmfohxXx0hoGJFHN9Bc=633XYxmcp+OA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:
> Without sorting, isnt the scope of a recursive UNION with custom datatypes
> pretty restrictive?
All the default data types are hashable. It's not hard to add a hash
operator class. In a clean slate design it would probably have been
simpler to just make it a requirement that any data type provide a
default hash operator (and probably a default btree comparator).
Postgres provides a lot of degrees of freedom but it should probably
be considered best practice to just provide both even if you don't
envision one or the other being used directly by users for indexes.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-04-27 01:36:28 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |
| Previous Message | Alfred Perlstein | 2014-04-27 01:25:19 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |