Greg Stark <st...@mit.edu> writes: > On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma <atri.j...@gmail.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. A btree opclass requires that you invent some one-dimensional sort order for the datatype, which might be a difficult thing; so I think it's fully reasonable not to require datatypes to have btree support. Hashing doesn't require any semantic assumptions beyond having an equality rule, which is clearly *necessary* if you want to do stuff like UNION or DISTINCT. So from that standpoint it's perfectly reasonable for recursive UNION to require a hashable equality operator, whereas the other case of requiring a sortable operator would be a lot harder to defend. Having said that, I can also believe that there might be datatypes for which implementing a hash function would be a lot harder than implementing sorting; this could be true if your equality rule allows for a lot of different physical representations of "equal" values. But I'm not so excited about such cases that I want to do the work of figuring out a way to implement recursive UNION by sorting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers