Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
От | Peter Eisentraut |
---|---|
Тема | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt |
Дата | |
Msg-id | 78fdbf09-ec9a-498f-91bd-392fc486117b@eisentraut.org обсуждение исходный текст |
Ответ на | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
|
Список | pgsql-hackers |
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.
Вложения
В списке pgsql-hackers по дате отправления: