Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>

To: Álvaro Herrera <alvherre@kurilemu.de>, jian he <jian.universality@gmail.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kirill Reshke <reshkekirill@gmail.com>

Date: 2025-09-12T13:41:18Z

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 →

CREATE STATISTICS: improve misleading error message
- cbd3732cbbaa 14.20 landed
- 4529861cc408 15.15 landed
- f30c04682cdf 16.11 landed
- f9b41f3e1ecd 17.7 landed
- 38883916e41c 18.0 landed
- 9ec0b29976b6 19 (unreleased) landed
- f9a7622483c3 15.15 landed
- f225473cbae2 19 (unreleased) landed
- e9fb314c7ad8 17.7 landed
- d84a6c3dad1f 16.11 landed
- b830f9d67463 14.20 landed
- 3eea4dc2c7cf 18.0 landed
Glossary: improve definition of "relation"
- 16a9165ce4a4 19 (unreleased) landed
Extended statistics on expressions
- a4d75c86bf15 14.0 cited

Attachments

v4-0001-CREATE-STATISTICS-improve-misleading-error-messag.patch (text/plain) patch v4-0001

On 05.09.25 14:30, Peter Eisentraut wrote:
> On 29.08.25 14:48, Álvaro Herrera wrote:
>> On 2025-Aug-29, jian he wrote:
>>
>>> On Fri, Aug 29, 2025 at 5:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>>>> 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.
>>>
>>> https://www.postgresql.org/docs/current/sql-copy.html
>>> use "COPY TO can be used only with plain tables, not views, and does
>>> not copy rows from child tables or child partitions"
>>
>> I'm inclined to think that we should only mention partitioned tables
>> specifically when they for some reason deviate from what we do for
>> regular tables, i.e., what Tom is saying.  I don't think we've had an
>> explicit, consistent rule for that thus far, so there may be places
>> where we fail to follow it.
>>
>> Anyway, I have pushed the error message change.
> 
> I think this message is still wrong.  The check doesn't even look at the 
> relation kind, which is what the message is implying.  (If the message 
> were about relkinds, then it should use 
> errdetail_relkind_not_supported().)  It checks that the from list entry 
> is a table name instead of some other thing like VALUES or JOIN.  So it 
> should be something like
> 
> CREATE STATISTICS only supports plain table names in the FROM clause

I propose the attached patch to fix this.  I think this restores the 
original meaning better.