Re: pg_stat_statements: Remove (errcode...) framing parentheses in erport(...)

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, m(dot)litsarev(at)postgrespro(dot)ru, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_stat_statements: Remove (errcode...) framing parentheses in erport(...)
Date: 2026-06-25 21:05:10
Message-ID: CALj2ACXRwOBv=REWfZp+-1BQCchF1Xa6HbJTPZ30xQRA4=u+Zw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Jun 25, 2026 at 1:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Sami Imseih <samimseih(at)gmail(dot)com> writes:
> > e3a87b499 states "There's no intention to make wholesale
> > changes of existing ereport calls ..."
>
> > Why do it for pg_stat_statements only when there are a bunch
> > of other places?
>
> I think we should flat out reject this patch. It makes no functional
> improvement while creating a merge hazard for future back-patches.
> That hazard might not be very large for just changing these few
> spots, but any more-aggressive attempt at changing existing ereports'
> style will certainly result in pain.
>
> As e3a87b499 said, there was no plan to change existing code and
> I think that decision should still stand.

+1 to what's said above. The merge burden is real (recently it took me
more than 30 minutes just to create patches for back-branches even
though most of the code remains the same in the function being
changed). IMHO, it's not worth the cycles.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haibo Yan 2026-06-25 21:31:06 Re: Optimize UUID parse using SIMD
Previous Message Tom Lane 2026-06-25 20:46:05 Re: [BUG] ECPG crash with union type