On Thu, Nov 13, 2025 at 5:41 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
>
> > @@ -15658,10 +15658,19 @@ ATPostAlterTypeParse(Oid oldId, Oid oldRelId, Oid refRelId, char *cmd,
> > querytree_list = list_concat(querytree_list, afterStmts);
> > }
> > else if (IsA(stmt, CreateStatsStmt))
> > + {
> > + RangeTblEntry *rte;
> > + CreateStatsStmt *ss = castNode(CreateStatsStmt, stmt);
> > +
> > + rte = makeNode(RangeTblEntry);
> > + rte->rtekind = RTE_RELATION;
> > + rte->relid = oldRelId;
> > + rte->rellockmode = ShareUpdateExclusiveLock;
> > + ss->rtable = list_make1(rte);
> > +
> > querytree_list = lappend(querytree_list,
> > - transformStatsStmt(oldRelId,
> > -
(CreateStatsStmt*) stmt,
> > -
cmd));
> > + transformStatsStmt(ss, cmd));
> > + }
> > else
> > querytree_list = lappend(querytree_list, stmt);
> > }
>
> Hmm, how would this part here work in the hypothetical world where a
> stats object references multiple relations?
>
hi.
For extended statistics that span multiple relations (hypothetically),
we should have the OIDs of
all involved relations within the pg_statistic_ext catalog. Without this , it's
hard to do statistic's expression deparse, changing column data types
or generation
expressions. Catalog pg_depend do have statistics associated relation OIDs
information, relying on it for statistical expression deparsing would be more
complicated.
Once pg_statistic_ext have all relation oid information,
RememberStatisticsForRebuilding will not only collecting
AlteredTableInfo->changedStatisticsOids, it will aslo collect the OID of other
relations associated with this statistic.
For the above quoted part, we should construct a RangeTblEntry for
each associated
relation (OID).
Obviously transformStatsStmt itself needs to figure out how to
deal with multi-relation expressions.
rebased and minor polishing.
--
jian
https://www.enterprisedb.com
