From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
cc: jian he <jian.universality@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Kirill Reshke <reshkekirill@gmail.com>
Subject: Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
In-reply-to: <202508282133.uwntzsze7cdl@alvherre.pgsql>
References: <202508282133.uwntzsze7cdl@alvherre.pgsql>
Comments: In-reply-to =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
	message dated "Thu, 28 Aug 2025 23:33:42 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1942412.1756417599.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Aug 2025 17:46:39 -0400
Message-ID: <1942413.1756417599@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1942413.1756417599%40sss.pgh.pa.us>
Precedence: bulk

=3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera <alvherre@kurilemu.de> writes:
> I propose to use this report:

> ERROR:  cannot create statistics on specified relation
> DETAIL:  CREATE STATISTICS only supports tables, materialized views, for=
eign tables, and partitioned tables.

WFM, although I think you could shorten it to "tables, materialized
views, and foreign tables".  We generally expect that partitioned
tables are included when saying "tables", no?  I'm not dead set on
that either way, though.

> While looking at this whole thing, I noticed that this code is somewhat
> bogus in a different way: we're resolving the relation name twice, both
> here in ProcessUtilitySlow() (to pass to transformStatsStmt), and later
> again inside CreateStatistics().  It's really strange that we decided
> not to pass the relation Oids as a list argument to CreateStatistics.  I
> suggest to change that as the first attached patch.

I think this is a good idea, but I'm not sure that the locking
considerations are straight in this version.  Once we translate a
relation name to OID, we'd better hold lock on the rel continuously to
the end of usage of that OID.  It looks like you do, but then couldn't
the

+		rel =3D relation_open(relid, ShareUpdateExclusiveLock);

in CreateStatistics use NoLock to signify that we expect to have
the lock already?

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.

			regards, tom lane