From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw fails to see that array type belongs to extension |
Date: | 2024-01-08 11:21:24 |
Message-ID: | aa40df04-1fde-40d5-a1d8-9ada42efc7ca@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-dependency-of-array-of-type-owned-by-extension.patch | text/x-patch | 1002 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-01-08 11:23:14 | Re: brininsert optimization opportunity |
Previous Message | Richard Guo | 2024-01-08 11:14:11 | Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 |