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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
