On Mon, Jul 13, 2020 at 5:59 PM Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > >> > If we really want to print something nicer, I'd say it needs to be a > >> > special function in the BRIN opclass. > >> > >> If that can be done, then +1. We just need to ensure that the function > >> knows and can verify the type of index that the value comes from. I > >> guess we can pass the index OID so that it can extract the opclass from > >> catalogs to verify. > > > >+1 from me, too. Perhaps we can have it as optional. If a BRIN opclass > >doesn't have it, the 'values' can be null. > > > > I'd say that if the opclass does not have it, then we should print the > bytea value (or whatever the opclass uses to store the summary) using > the type functions.
I've read the recent messages in this thread and I'd like to share my thoughts. I think the way brin_page_items() displays values is not really generic. It uses a range-like textual representation of an array of values, while that array doesn't necessarily have range semantics. However, I think it's good that brin_page_items() uses a type output function to display values. So, it's not necessary to introduce a new BRIN opclass function in order to get values displayed in a human-readable way. Instead, we could just make a standard of BRIN value to be human readable. I see at least two possibilities for that. 1. Use standard container data-types to represent BRIN values. For instance we could use an array of ranges instead of bytea for multirange. Not about how convenient/performant it would be. 2. Introduce new data-type to represent values in BRIN index. And for that type we can define output function with user-readable output. We did similar things for GiST. For instance, pg_trgm defines gtrgm type, which has no input and no output. But for BRIN opclass we can define type with just output. BTW, I've applied the patchset to the current master, but I got a lot of duplicate oids. Could you please resolve these conflicts. I think it would be good to use high oid numbers to evade conflicts during development/review, and rely on committer to set final oids (as discussed in [1]). Links 1. https://www.postgresql.org/message-id/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-%3DeaochT0dd2BN9CQ%40mail.gmail.com ------ Regards, Alexander Korotkov