Re: postgres_fdw fails to see that array type belongs to extension

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

In response to

Responses

Browse pgsql-hackers by date

  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