From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
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-23 15:04:04 |
Message-ID: | 1318391.1711206244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> One thing I'm not 100% sure of is whether record_larger() should make
> a copy of its arguments or the current implementation is safe.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-23 16:31:51 | Re: [PATCH] plpython function causes server panic |
Previous Message | Tomas Vondra | 2024-03-23 13:47:12 | Re: pg_upgrade --copy-file-range |