Re: RFC: Remove contrib entirely
От | Neil Tiffin |
---|---|
Тема | Re: RFC: Remove contrib entirely |
Дата | |
Msg-id | 95C83718-69F1-4DEA-B116-E77A4D1547F4@neiltiffin.com обсуждение исходный текст |
Ответ на | Re: RFC: Remove contrib entirely (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: RFC: Remove contrib entirely
|
Список | pgsql-hackers |
> On Jun 4, 2015, at 10:55 AM, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote: > > Personally, I'd rather we publish a list of formally vetted and approved versions of PGXN modules. There are many benefitsto that, and the downside of not having that stuff as part of make check would be overcome by the explicit testingwe would need to have for approved modules. I have looked at PGXN and would never install anything from it. Why? Because it is impossible to tell, without inside knowledgeor a lot of work, what is actively maintained and tested, and what is an abandoned proof-of-concept or idea. Thereis no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can be runto prove the module works correctly with a particular version of pg. There are many modules that have not been updatedfor several years. What is their status? If they break is there still someone around to fix them or even cares aboutthem? If not, then why waste my time. So adding to Jim’s comment above, anything that vets or approves PGXN modules is, in my opinion, essentially required tomake PGXN useful for anything other than a scratchpad. A big help would be to pull in the date of the last git commitin the module overview and ask the authors to edit the readme to add what major version of pg the author last testedor ran on. When I install from contrib, at least I have some minimal assurance that the code is meant to work with the correspondingversion of pg. Neil
В списке pgsql-hackers по дате отправления: