Michael Paquier <mich...@paquier.xyz> writes: > On Mon, Jul 08, 2024 at 12:20:30PM +0300, Aleksander Alekseev wrote: > - and arrays of any of these types. > + and also arrays and records of any of these types.
> This update of the docs is incorrect, no? Records could include much > more types than the ones currently supported for min()/max(). Yeah, actually the contained data types could be anything with btree sort support. This is true for arrays too, so the text was wrong already. I changed it to + and also arrays and composite types containing sortable data types. (Using "composite type" not "record" is a judgment call here, but I don't see anyplace else in func.sgml preferring "record" for this meaning.) > I am not sure to get the concerns of upthread regarding the type > caching in the context of an aggregate, which is the business with > lookup_type_cache(), especially since there is a btree operator > relying on record_cmp(). Tom, what were your concerns here? Re-reading, I was just mentioning that as something to check, not a major problem. It isn't, because array min/max are already relying on the ability to use fcinfo->flinfo->fn_extra as cache space in an aggregate. (Indeed, the array aggregate code is almost identical to where we ended up.) AFAICS this is good to go. I made a couple of tiny cosmetic adjustments, added a catversion bump, and pushed. regards, tom lane