Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt - Mailing list pgsql-hackers

From jian he
Subject Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
Date
Msg-id CACJufxGmqkifdj0fBoNhDKoHFgz3v_qo1v5nDDqj-gY1-YC3hA@mail.gmail.com
Whole thread Raw
In response to Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Should io_method=worker remain the default?
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible