Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

Поиск
Список
Период
Сортировка
От jian he
Тема Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
Дата
Msg-id CACJufxGmqkifdj0fBoNhDKoHFgz3v_qo1v5nDDqj-gY1-YC3hA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt  (Álvaro Herrera <alvherre@kurilemu.de>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления: