Thank you. On Tue, Jun 28, 2016 at 11:06 PM Oleg Bartunov <obartu...@gmail.com> wrote:
> 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 >>> >>
