Horton

Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

jian he <jian.universality@gmail.com>

View thread
From: jian he <jian.universality@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-11-13T03:44:45Z
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 →

  1. CREATE STATISTICS: improve misleading error message

  2. Glossary: improve definition of "relation"

  3. Extended statistics on expressions

Attachments

hi.

new patch attached.

Summary of the problem we’re trying to solve:
1. ProcessUtility for T_CreateStatsStmt, there’s a lot of code that doesn’t
belong there.
2. The current pattern of repeatedly performing RangeVar lookups isn’t ideal —
we should perform the lookup once and then use the corresponding relation OID
for subsequent operations.

The main part this patch is copied from
https://postgr.es/m/CA+TgmobyMXzoEzscCRDCggHRCTp1TW=Dm9pEhmwOYKos43WDAg@mail.gmail.com

Below is a copy of the commit message.
------------------
Previously, a lot of code would be run in the ProcessUtility pipeline,
where it is not welcome (that's supposed to be just a giant dispatcher
switch).  Move the parse analysis code to CreateStatistics() instead,
which then means we don't need to open the relation twice; it also
allows us to give a better error message when something other than a
relation name is given in the FROM clause.

Generally we should avoid look up the same less-than-fully-qualified name
multiple times, we might get different answers due to concurrent activity, and
that might create a security vulnerability, along the lines of CVE-2014-0062.

Refactor so that a CreateStatsStmt carries both the untransformed FROM clause
and the range table that we get when it's transformed. That way, once the name
lookups have been done, we can propagate the results forward to future
processing steps and avoid ever repeating the lookup.
------------------

--
jian
https://www.enterprisedb.com/