Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnd3H-00EE0k-1T for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2024 11:27:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rnd3F-002U0t-6Y for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2024 11:27:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnd3E-002U0l-TJ for pgsql-hackers@lists.postgresql.org; Fri, 22 Mar 2024 11:27:09 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rnd3C-005tMw-Sa for pgsql-hackers@lists.postgresql.org; Fri, 22 Mar 2024 11:27:08 +0000 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-56bdf694a81so726488a12.3 for ; Fri, 22 Mar 2024 04:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711106825; x=1711711625; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ku/8uW/I93HcK5g++3xsvGJT2s29OxJLcvi+vEFCqWM=; b=TQINorSf7nWJ+vkUg/2GPDHd+E2oOC6VO5dvn0YmmyJv7sTWUCSRpnUlF/emfD05Zv nopak+ylcPNpiz4pabOFzAGTOZQsx3quGKWELn9rbAI3MStwMfQ9yGXBC9tpZmibWvKy 81dU0a2fW5D+DXydXowCYhOqFdnMqGX0gPsgP7YM929FwYTAyG3Oyl8XjgkywVpk1DHd AYhSrxKWjQ1I1FpZsi+qcCqGL79XYRTljsUfyx+HsYyLUfajZecihryEpuwOrzI4obpG PTvgciGolhA/4FgDRyjdfpGQ65c/EIu+XYiNbbDn9iP4WRED13J3ZV4Grlz65qfN//UH uKEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711106825; x=1711711625; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ku/8uW/I93HcK5g++3xsvGJT2s29OxJLcvi+vEFCqWM=; b=pMJMUd7hij4lGnlgsonlVt8U6sF3srEeZa1AAuRzy/bcBTe9atDdaHoYxNhMJVQV2e LQ7lZcjr2GpoQK3J5cUER6l8XIVFl0EAvj3wTT0SvIFnjllz056yGQLXNl/ZAh5DQwbE dgbD9zwoOKps8JmMzSOvwq7lZu/+6qXGj66mjMiB+La1GcWxnnaaI66wgox/xmMHoBBH XVn9jm/evzGho0G+nHuNBKUJPUa/wZ5ae0vDYfN48Z68Pfo3MirydkVb1xr1R72V8+qz hl3hFXHEpLlz/Ry+1pVCesrSx08yq+iwwgxaG/5Swnu9xIwqzj3w/NgLUq4tLf2LtWtB PJvg== X-Gm-Message-State: AOJu0Yw4i4y8896EPTG9LCN2hOJIrPs/oH7D6VDP/puU268xnJ3t4g0t 9dnsP0nZnOtxXfTgcTsVsilDtuLEe4Z5Vfg9wlH3LoauG0evOcEjN7216pCaqGmn0FnrQfRdIKv S0bYE6OTmt3B/C+jfEXOWyN65Qu9ZM3sDeBk= X-Google-Smtp-Source: AGHT+IHenZG1l+sjxfY4BQapNrKUxPxf9V8ITu2Tjyc5un5BB0sdtQFKcCOjxuQzEPqF2Ag9X5Fy5f7TmgJQ2JNqb/E= X-Received: by 2002:a50:f68e:0:b0:568:93bb:d0c2 with SMTP id d14-20020a50f68e000000b0056893bbd0c2mr1472536edn.20.1711106824462; Fri, 22 Mar 2024 04:27:04 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Viliam_=C4=8Eurina?= Date: Fri, 22 Mar 2024 12:26:27 +0100 Message-ID: Subject: MIN/MAX functions for a record To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000071ea6106143e1ad8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000071ea6106143e1ad8 Content-Type: text/plain; charset="UTF-8" In my queries I often need to do MIN/MAX for tuples, for example: SELECT MAX(row(year, month)) FROM (VALUES(2025, 1), (2024,2)) x(year, month); This query throws: ERROR: function max(record) does not exist In this case you can replace it with `MAX((year||'-'||month||'-1')::date)`. However in my case I have an event table with `event_time` and `text` columns, I'm grouping that table by some key and want to have the text for the newest event. I would do `MAX(ROW(event_time, text)).text`. Workarounds for this are clumsy, e.g. with a subquery with LIMIT 1. The lack of this feature is kind of unexpected, because the `>` operator or `GREATEST` function are defined for records: SELECT GREATEST((2025, 1), (2024, 2)), (2025, 1) > (2024, 2) Was this ever discussed or is there something preventing the implementation? Viliam --00000000000071ea6106143e1ad8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my queries I often need to do MIN/MAX for tuples, = for example:

=C2=A0 SELECT MAX(row(year, month))=C2=A0
=C2=A0 FROM (VALUES(2025, 1), (2024,2)) x(year, mont= h);

This query throws:

=
=C2=A0 =C2=A0 ERROR: function ma= x(record) does not exist

In this case you can replace it with `MAX((year||= '-'||month||'-1')::date)`. However in my case I have an eve= nt table with `event_time` and `text` columns, I'm grouping that table by=20 some key and want to have the text for the newest event. I would do=20 `MAX(ROW(event_time, text)).text`. Workarounds for this are clumsy, e.g. wi= th a subquery with LIMIT 1.

The lack of= this feature is kind of unexpected, because the `>` operator or `GREATE= ST` function are defined for records:

=C2=A0=C2=A0=C2=A0 SELECT=C2=A0
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 GREATEST((2025, 1), (2024, 2)),=C2=A0
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (2025, 1) > (2024, 2)
=

Was this ever discussed or is there something preventin= g the implementation?

Viliam
--00000000000071ea6106143e1ad8--