Re: libpq-oauth: a mid-beta naming check
От | Jelte Fennema-Nio |
---|---|
Тема | Re: libpq-oauth: a mid-beta naming check |
Дата | |
Msg-id | CAGECzQTojfE6iOFT2c1Yp+1ezQYKBT1jGXmXa2W_M8pQGc1_5w@mail.gmail.com обсуждение исходный текст |
Ответ на | libpq-oauth: a mid-beta naming check (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: libpq-oauth: a mid-beta naming check
|
Список | pgsql-hackers |
On Tue, 5 Aug 2025 at 01:20, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > As far as I know, that > work necessarily includes designing a stable ABI and figuring out a > trusted place that users can put their plugins into. If we can do > both, I think we can get rid of the -MAJOR versioning scheme entirely, > because our use case will have been subsumed by the more general > framework. > > So, as we approach Beta 3: can anyone think of a way that this plan will fail? It's not entirely clear what plan exactly you talk about here. Are you saying you want to remove the -MAJOR suffix now for PG18? Or you want to postpone doing that until PG19, when you would have designed a stable API? Based on my current understanding from what you wrote, I think that second option would make sense, and the first option seems sketchy. Because we don't know yet what the PG19 API will look like. Also, the breakage during libpq major upgrades that you describe, while unfortunate, doesn't seem completely terrible. This only impacts people updating system packages in place on machines, which (based on my experience) has started to become a minority in production setups. Also this will obviously only impact oauth users, which I expect not to be that many right away. If your goal is to remove this during-upgrade breakage after PG19, then I'd say that seems totally fine for a new feature.
В списке pgsql-hackers по дате отправления: