Re: BUG #18407: ALTER TABLE SET SCHEMA on foreign table with SERIAL column does not move sequence to new schema
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vidushi2504@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2024-03-25T16:17:25Z
Lists: pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> I created a foreign table with a serial column and then moved the table to a
> different schema. The sequence bound to the table column wasn't moved to the
> new schema. I expected the sequence to be moved as well just like it works
> for regular tables.
Hmm ... that does seem fairly inconsistent. It looks like the cause
is in AlterTableNamespaceInternal:
/* Fix other dependent stuff */
if (rel->rd_rel->relkind == RELKIND_RELATION ||
rel->rd_rel->relkind == RELKIND_MATVIEW ||
rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
{
AlterIndexNamespaces(classRel, rel, oldNspOid, nspOid, objsMoved);
AlterSeqNamespaces(classRel, rel, oldNspOid, nspOid,
objsMoved, AccessExclusiveLock);
AlterConstraintNamespaces(RelationGetRelid(rel), oldNspOid, nspOid,
false, objsMoved);
}
It's probably reasonable to have this relkind gating for
AlterIndexNamespaces, although I'm not sure it saves much to
skip that, either. But we can have sequences attached to
foreign tables, and I think maybe constraints as well.
Maybe it'd be best to just drop this relkind check altogether?
regards, tom lane
Commits
-
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
- fad3b5b5acb1 17.0 landed
- b48eda4e5481 15.7 landed
- a8b7408686a5 12.19 landed
- 97de2a15992f 13.15 landed
- 7445f092814d 16.3 landed
- 66bbad581ce2 14.12 landed