Hi,
On 12/27/23 18:38, Tom Lane wrote:
Hmm. It seems odd that if an extension defines a type, the type is
listed as a member of the extension but the array type is not.
That makes it look like the array type is an externally-created
thing that happens to depend on the extension, when it's actually
part of the extension. I'm surprised we've not run across other
misbehaviors traceable to that.
Agreed.
Of course, fixing it like that leads to needing to change the
contents of pg_depend, so it wouldn't be back-patchable. But it
seems like the best way in the long run.
The attached patch just adds a 2nd dependency between the array type and
the extension, using recordDependencyOnCurrentExtension(). It seems like
that the other internal dependency on the element type must stay? If
that seems reasonable I can add a test to modules/test_extensions. Can
extensions in contrib use test extension in their own tests? It looks
like postgres_fdw doesn't test any of the shippability logic.
--
David Geier
(ServiceNow)
From de23a4e9f1b0620a5204594139568cdcb3d57885 Mon Sep 17 00:00:00 2001
From: David Geier <geidav...@gmail.com>
Date: Mon, 8 Jan 2024 10:58:21 +0100
Subject: [PATCH] Fix dependency of array of type owned by extension
---
src/backend/catalog/pg_type.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/backend/catalog/pg_type.c b/src/backend/catalog/pg_type.c
index d7167108fb..3544a3af1a 100644
--- a/src/backend/catalog/pg_type.c
+++ b/src/backend/catalog/pg_type.c
@@ -724,8 +724,10 @@ GenerateTypeDependencies(HeapTuple typeTuple,
if (OidIsValid(typeForm->typelem))
{
ObjectAddressSet(referenced, TypeRelationId, typeForm->typelem);
- recordDependencyOn(&myself, &referenced,
- isImplicitArray ? DEPENDENCY_INTERNAL : DEPENDENCY_NORMAL);
+ recordDependencyOn(&myself, &referenced, isImplicitArray ? DEPENDENCY_INTERNAL : DEPENDENCY_NORMAL);
+
+ if (makeExtensionDep)
+ recordDependencyOnCurrentExtension(&myself, rebuild);
}
}
--
2.39.2
