From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | vidushi2504(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18407: ALTER TABLE SET SCHEMA on foreign table with SERIAL column does not move sequence to new schema |
Date: | 2024-03-25 16:17:25 |
Message-ID: | 2497748.1711383445@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-25 19:04:15 | Re: Unexpected Name Resolution Behavior with ORDER BY COLLATE Clause in PostgreSQL 16.2 |
Previous Message | Scott Ribe | 2024-03-25 16:16:11 | Re: BUG #18405: flaw in dump of inherited/dropped constraints |