Re: MIN/MAX functions for a record

Michael Paquier <michael(at)paquier(dot)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