On Fri, Jan 2, 2026 at 4:25 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> First two steps seems to add Oids along with RangeVars. It seems suspicious to me.
> Parse Nodes seem to use "textual" identifiers without resolving them to Oids. Oids are specific to session catalog
snapshot,but parse nodes
> By adding Oid fields we will have to check both RangeVars and Oids all over the code.
> Other INCLUDING options (indexes, constraints) don't modify their statement nodes this way - they create fresh nodes
withresolved references.
It seems like what generateClonedIndexStmt() does for the relation name is just:
index->relation = heapRel;
This is not a "resolved reference", which I would understand to mean
an OID in this context. In fact, if heapRel->schemaname were ever NULL
here, this would be at least a bug and possibly a security issue.
However, I don't think that ever happens. ProcessUtilitySlow() calls
transformCreateStmt(), which forces the RangeVar to be
fully-qualified, and then ProcessUtilitySlow() fishes out the
transformed RangeVar so that it gets passed through to
expandTableLikeClause(), which in turn passes it through to
generateClonedIndexStmt() and generateClonedExtStatsStmt(). Similarly
constraints are handled by using that same transformed (i.e. forcibly
schema-qualified) RangeVar in the AlterTableStmt we construct.
To be honest, I find this all incredibly ugly. I think that
translating from names to OIDs and back to names so that we can later
translate back to OIDs is a horrendous, bug-prone mess. Nor is the
problem confined to table names. For example,
generateClonedIndexStmt() needs to translate the AM name and
tablespace name and any column names back to textual format so that
when we actually create the index we can redo the translation in the
forward direction and hopefully get the right answer.
But having said that it's incredibly ugly and I don't like anything
about it, it also does seem to be the established pattern. As you say,
it seems as though the patch makes CREATE LIKE ... (INCLUDING
TRIGGERS) work differently from other cases, and I'm guessing that's
not what we want to do. It's better to use the same ugly hack
consistently than to use different ugly hacks in different places.
Then if somebody ever decides to try to clean this up, they can clean
up all the cases in the same way.
--
Robert Haas
EDB: http://www.enterprisedb.com
