| commit | 9effc4608e1f6d19546a0e0f64320f4b0dd10c3c | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Thu, 9 May 2024 16:19:43 +0000 (9 12:19 -0400) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Thu, 9 May 2024 16:19:52 +0000 (9 12:19 -0400) | ||
| tree | b0c4d38060d95ee3b4a7cd12368b531520e9d433 | treesnapshot (tar.gz zip) |
| parent | d82ab9fc31aa62d94c26d7df98e65c6ceaadb01f | commitdiff |
Repair ALTER EXTENSION ... SET SCHEMA.
It turns out that we broke this in commit e5bc9454e, because
the code was assuming that no dependent types would appear
among the extension's direct dependencies, and now they do.
This isn't terribly hard to fix: just skip dependent types,
expecting that we will recurse to them when we process the parent
object (which should also be among the direct dependencies).
But a little bit of refactoring is needed so that we can avoid
duplicating logic about what is a dependent type.
Although there is some testing of ALTER EXTENSION SET SCHEMA,
it failed to cover interesting cases, so add more tests.
Discussion: https://postgr.es/m/930191.1715205151@sss.pgh.pa.us
It turns out that we broke this in commit e5bc9454e, because
the code was assuming that no dependent types would appear
among the extension's direct dependencies, and now they do.
This isn't terribly hard to fix: just skip dependent types,
expecting that we will recurse to them when we process the parent
object (which should also be among the direct dependencies).
But a little bit of refactoring is needed so that we can avoid
duplicating logic about what is a dependent type.
Although there is some testing of ALTER EXTENSION SET SCHEMA,
it failed to cover interesting cases, so add more tests.
Discussion: https://postgr.es/m/930191.1715205151@sss.pgh.pa.us