On Sat, Feb 8, 2020 at 6:50 PM Peter Geoghegan <pg@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