Re: Policy for Abandoned Extensions

From: Hannu Krosing <hannuk(at)google(dot)com>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Policy for Abandoned Extensions
Date: 2026-10-10 19:55:54
Message-ID: CAMT0RQTZx9KfZLgHdm3k0zK26SYSga=F8sCcJacbdYbc99k78Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Maybe we can add "end-of-life" versions to extensions?

So if we have versions x.y.z-alpha and x.y.z-beta before x.y.z , maybe we
can also have x.y.z-abandoned and/or x.y.z-unmaintained at the other end?

So anyone installing such will habe better chance to notice.

And we could make them als sort after normal versions in
postgres_debversion and pg_debver :)

---
Hannu

On Sat, Oct 10, 2026 at 8:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Joe Conway <mail(at)joeconway(dot)com> writes:
> > It may be impractical, but given cases like the XZ Utils backdoor
> > situation (i.e where a malicious person showed up offering to "help"
> > maintain an open source project where the original maintainer was
> > stepping away), it seems like any transfer process needs a vetting step.
>
> Yeah, if the replacement maintainer is malicious or even merely
> incompetent, things could be worse than leaving the extension alone.
> But that wasn't on David's list of worries, so I imagine he thinks
> that's a soluble problem.
>
> regards, tom lane
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2026-10-10 19:58:41 Re: Policy for Abandoned Extensions
Previous Message Hannu Krosing 2026-10-10 19:45:19 Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)