Re: [HACKERS] removing tsearch2
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] removing tsearch2 |
Дата | |
Msg-id | CA+TgmoYxoNO01t1D3jrFOXGLfmBfq5FMpnGF176ROP3EOGxe4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] removing tsearch2 (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
[HACKERS] Official adoption of PGXN (was: removing tsearch2)
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
|
Список | pgsql-hackers |
On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > Right; I think we need at least some amount of pgxn buildfarm coverage. > There probably also needs to be a way to officially bless certain > distributions. Unless there's a pretty significant need for an official > extension to be in contrib, it should go into PGXN. I'm not sure a need-based test is going to be entirely the right thing. The advantage of having something in contrib is that the core developers will maintain it for you. When things change from release to release, everything in contrib necessarily gets updated; things on PGXN or elsewhere only get updated if their owners update them. There are several good things about that. First, it means that people can rely on the stuff in contrib mostly sticking around for future releases, except occasionally when we decide to drop a module. Second, it gives maintainers of external modules examples of what they need to do to update their code when we change the core APIs. Third, it's probably actually more efficient for one person to go sweep through a large number of modules and fix them all at once than if those things were all on PGXN with separate owners. Now, you can overdo that: I don't want to be responsible for every module on PGXN or anything close to it. But on balance I think there's a good case for shipping a substantial set of modules in contrib. I think, in general, that we've done a good job increasing the quality of contrib over time. Pretty much all of the new stuff we've added is fairly solid, and we cleaned things up significantly by moving test code to src/test/modules. But we've still got some older modules in contrib whose quality and general usefulness is pretty questionable IMV: earthdistance, intagg, intarray, isn, and of course the eternally-deprecated but never-actually-removed xml2. I'm not in a hurry to expend a lot of energy removing any of that stuff, and I think we might be reaching our quota of backward-incompatible changes for this release, but it's questionable in my mind whether having those things there works out to a net plus. There's a lot of good stuff in contrib, though, and I don't think we should be averse to adding more in the future. It shouldn't be just that any random contrib module somebody writes can get dropped into the core distribution, but I think we ought to be open to reasonable proposals to add things there when it makes sense. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: