Re: [PATCH] Report malformed integer aggregate states as array errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Strydom, Matthys" <strydom(at)amazon(dot)com>
Cc: "Burd, Greg" <gregburd(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Report malformed integer aggregate states as array errors
Date: 2026-11-12 17:57:58
Message-ID: 47977.1794506278@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Strydom, Matthys" <strydom(at)amazon(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> It's not reasonable for people to call these functions directly ---
>> indeed there's been discussion about making that impossible, and then
>> stripping out some of these error checks.

> I would be interested in helping make these aggregate support functions
> impossible to call directly. Could you point me to the earlier
> discussion, or to the preferred direction if one has emerged?

Here are a couple of recent threads touching on this:

https://www.postgresql.org/message-id/flat/1ddc2a6f-4b26-43d9-9f3b-5b5db98a486d%40gmail.com
https://www.postgresql.org/message-id/flat/762e811a-6584-4b03-a6ca-52600adcd6e9%40gmail.com

I'm not sure there's full consensus on what to do, but the second
choice (declare these aggregates' transition type INTERNAL rather
than an array) would get the job done with a smaller blast radius.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-11-12 18:03:17 Re: pg_walinspect: fix LSN validation messages and empty range handling
Previous Message Tom Lane 2026-11-12 17:39:42 Re: A gap in preventing bogus parameterizations in a798660ebe3