> On Jun 4, 2015, at 10:55 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > > Personally, I'd rather we publish a list of formally vetted and approved > versions of PGXN modules. There are many benefits to that, and the downside > of not having that stuff as part of make check would be overcome by the > explicit testing we 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 knowledge or a lot of work, what is actively maintained and tested, and what is an abandoned proof-of-concept or idea. There is no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can be run to prove the module works correctly with a particular version of pg. There are many modules that have not been updated for several years. What is their status? If they break is there still someone around to fix them or even cares about them? 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 to make PGXN useful for anything other than a scratchpad. A big help would be to pull in the date of the last git commit in the module overview and ask the authors to edit the readme to add what major version of pg the author last tested or ran on. When I install from contrib, at least I have some minimal assurance that the code is meant to work with the corresponding version of pg. Neil -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
