On Sat, Feb 8, 2020 at 6:50 PM Peter Geoghegan <p...@bowt.ie> wrote: > My working assumption is that I only need to care about > opclass-declared input data types (pg_opclass.opcintype), plus the > corresponding collations -- the former can be used to lookup an > appropriate pg_amproc entry (i.e. B-Tree support function 4), while > the latter are passed to the support function to get an answer about > whether or not it's okay to use deduplication. This approach seems to > be good enough as far as the deduplication project's needs are > concerned. However, I think that I probably need to take a broader > view of the problem than that. Any guidance would be much appreciated.
v33 of the deduplication patch series was just posted. It included this infrastructure in a separate patch, which isn't that big on its own. See: https://www.postgresql.org/message-id/CAH2-WzmQGYDDoAETGhpGtJQRv_uFHMjvQZ6JdLV-sxGoCgLBNg%40mail.gmail.com Expert review of the opclass infrastructure still seems like a good idea. I'm sure that it does everything that the deduplication feature will ever need, but I'm a little concerned about painting myself into a corner as far as other things that use the API are concerned. In particular, I hope that I haven't failed to anticipate a requirement that the planner has for the new API. Thanks -- Peter Geoghegan
