On Wed, Jun 29, 2016 at 6:17 AM, M Enrique <enrique.mailing.li...@gmail.com> wrote:
> What's a good source code entry point to review how this is working for > anyarray currently? I am new to the postgres code. I spend some time > looking for it but all I found is the following (which I have not been able > to decipher yet). > Look on https://commitfest.postgresql.org/4/145/ > > [image: pasted1] > > Thank you, > Enrique > > > > On Tue, Jun 21, 2016 at 12:20 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Enrique MailingLists <enrique.mailing.li...@gmail.com> writes: >> > Currently creating an index on an array of UUID involves defining an >> > operator class. I was wondering if this would be a valid request to add >> as >> > part of the uuid-ossp extension? This seems like a reasonable operator >> to >> > support as a default for UUIDs. >> >> This makes me itch, really, because if we do this then we should logically >> do it for every other add-on type. >> >> It seems like we are not that far from being able to have just one GIN >> opclass on "anyarray". The only parts of this declaration that are >> UUID-specific are the comparator function and the storage type, both of >> which could be gotten without that much trouble, one would think. >> >> > Any downsides to adding this as a default? >> >> Well, it'd likely break things at dump/reload time for people who had >> already created a competing "default for _uuid" opclass manually. I'm not >> entirely sure, but possibly replacing the core opclasses with a single one >> that is "default for anyarray" could avoid such failures. We'd have to >> figure out ambiguity resolution rules. >> >> regards, tom lane >> >
