Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

jian he <jian.universality@gmail.com>

From: jian he <jian.universality@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-09-04T04:54:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. CREATE STATISTICS: improve misleading error message

  2. Glossary: improve definition of "relation"

  3. Extended statistics on expressions

Attachments

On Fri, Aug 29, 2025 at 8:48 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> > > Alternatively, maybe the right fix is to move the parse-analysis
> > > work into CreateStatistics altogether.  I think there is not a
> > > very good argument for ProcessUtilitySlow doing all that stuff.
> > > It's supposed to mainly just be a dispatching switch(), IMO.
> >
> > seems doable.
> > transformStatsStmt, CreateStatistics both used only twice, refactoring
> > arguments should be fine.
> > please check the attached POC, regress tests also added.
>
> Yeah, I like how this turned out.  I found out this was introduced in
> commit a4d75c86bf15.

Previously, CreateStatistics and ProcessUtilitySlow opened the same relation
twice with a ShareUpdateExclusiveLock.  This refactor ensures the relation is
opened with ShareUpdateExclusiveLock only once and also reduces redundant error
checks.
The logic is now more intuitive: we first error checking
CreateStatsStmt->relations and then call transformStatsStmt to parse analysis
CreateStatsStmt->exprs.

please check the attached refactor CreateStatsStmt.