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
signature.asc
Description: PGP signature
