Re: MIN/MAX functions for a record

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Viliam Ďurina <viliam(dot)durina(at)gmail(dot)com>
Subject: Re: MIN/MAX functions for a record
Date: 2024-03-25 10:38:55
Message-ID: CAJ7c6TO-b5-0kUQDVovWCmUNXEiN49qPcaSfCJm9EP77fHRfWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> I don't see any copying happening in, say, text_larger or
> numeric_larger, so this shouldn't need to either.
>
> Personally I'd write "record_cmp(fcinfo) > 0" rather than indirecting
> through record_gt. The way you have it is not strictly correct anyhow:
> you're cheating by not using DirectFunctionCall.
>
> Also, given that you're passing the fcinfo, there's no need
> to extract the arguments from it before that call. So it
> seems to me that code like
>
> if (record_cmp(fcinfo) > 0)
> PG_RETURN_HEAPTUPLEHEADER(PG_GETARG_HEAPTUPLEHEADER(0));
> else
> PG_RETURN_HEAPTUPLEHEADER(PG_GETARG_HEAPTUPLEHEADER(1));
>
> should do, and possibly save one useless detoast step. Or you could
> do
>
> if (record_cmp(fcinfo) > 0)
> PG_RETURN_DATUM(PG_GETARG_DATUM(0));
> else
> PG_RETURN_DATUM(PG_GETARG_DATUM(1));
>
> because really there's no point in detoasting at all.

Many thanks. Here is the corrected patch. Now it also includes MIN()
support and tests.

--
Best regards,
Aleksander Alekseev

Attachment Content-Type Size
v2-0001-Support-min-record-and-max-record-aggregates.patch application/octet-stream 6.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2024-03-25 10:38:59 Re: Introduce XID age and inactive timeout based replication slot invalidation
Previous Message Jelte Fennema-Nio 2024-03-25 10:32:29 Re: session username in default psql prompt?