On Wed, Oct 21, 2020 at 8:51 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Oct 8, 2020 at 5:54 PM Tomas Vondra > <tomas.von...@2ndquadrant.com> wrote: > > And is the oidvector actually needed? If we have the extra catalog, > > can't we track this simply using the regular dependencies? So we'd have > > the attcompression OID of the current compression method, and the > > preserved values would be tracked in pg_depend. > > If we go that route, we have to be sure that no such dependencies can > exist for any other reason. Otherwise, there would be confusion about > whether the dependency was there because values of that type were > being preserved in the table, or whether it was for the hypothetical > other reason. Now, admittedly, I can't quite think how that would > happen. For example, if the attribute default expression somehow > embedded a reference to a compression AM, that wouldn't cause this > problem, because the dependency would be on the attribute default > rather than the attribute itself. So maybe it's fine.
Yeah, and moreover in the new patchset, we are storing the compression methods in the new catalog 'pg_compression' instead of merging with the pg_am. So I think only for the preserve purpose we will maintain the attribute -> pg_compression dependency so it should be fine. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
