Re: Policy for Abandoned Extensions - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Policy for Abandoned Extensions
Date
Msg-id CAMT0RQTZx9KfZLgHdm3k0zK26SYSga=F8sCcJacbdYbc99k78Q@mail.gmail.com
Whole thread
In response to Re: Policy for Abandoned Extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Policy for Abandoned Extensions
List 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@sss.pgh.pa.us> wrote:
Joe Conway <mail@joeconway.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


pgsql-hackers by date:

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