On Fri, Oct 22, 2021 at 10:48:57AM +0300, Aleksander Alekseev wrote:
> ... where the slot is allocated with palloc0. The assumption that
> MakeSingleTupleTableSlot() returns valid TupleTableSlot* with zeroed
> tts_isnull[] seems reasonable, no?
Yes, I don't see any need to do something more here. The number of
arguments is fetched from the tuple descriptor itself, so the
allocation is sufficient.
> What confuses me is the fact that we have two procedures that do the
> same thing. Maybe one is redundant.
Do you have something in mind here?
Taking advantage of the catalog types and knowing that this is a
one-off, it is possible to recover dbid, classid, objid, objsubid and
refclassid. deptype can be mostly guessed from refclassid, but the
real problem is that refobjid is just lost because of the casting to a
char from and Oid.
[ ... Thinks more ... ]
Hmm. Wouldn't it be as simple as removing the entries in pg_shdepend
where dbid is NULL, and do an INSERT/SELECT with the existing entries
in pg_shdepend from the template database, updating dbid to the new
database? That would require users to know which template they used
as origin, as well as we could assume that no shared deps have changed
but that can be guessed by looking at all the misplaced fields. It is
true enough that users could make a lot of damage with chirurgy DMLs
on catalogs, though.
--
Michael
