Re: [HACKERS] Official adoption of PGXN
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Official adoption of PGXN |
Дата | |
Msg-id | 20170214203926.2zafjdzcaiosb4zz@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Official adoption of PGXN (Josh Berkus <josh@berkus.org>) |
Ответы |
Re: [HACKERS] Official adoption of PGXN
|
Список | pgsql-hackers |
On 2017-02-14 12:19:56 -0800, Josh Berkus wrote: > On 02/14/2017 12:05 PM, Tom Lane wrote: > > Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > >> First, just to clarify: my reasons for proposing "core adoption" of PGXN > >> are not technical in nature. > > > > What do you think "core adoption" means? Surely not that anything > > associated with PGXN would be in the core distro. > > One part of this would need to be having a designated committee of the > Postgres community pick a set of "blessed" extensions for packagers to > package. Right now, contrib serves that purpose (badly). One of the > reasons we haven't dealt with the extension distribution problem is that > nobody wanted to take on the issue of picking a list of blessed extensions. I don't see the trust problem being solved by them being blessed unless they're part of the regularly scheduled postgres back-branch releases. Which essentially requires them to be in core, or increase the release maintenance/management cost further. We sure could have levels between "random github repo" and "in core extension", but I don't see "bless external extensions" supplanting all contrib stuff. There's a few extension in contrib/ where that level would make sense, and surely more outside, but I think moving all of contrib to something externally managed would be horrible idea. > You have to admit that it seems really strange in the eyes of a new user > that ISN is packaged with PostgreSQL, whereas better-written and more > popular extensions (like plv8, pg_partman or pgq) are not. These actually seem like easy cases. plv8 has a massive external dependency, pg_partman is a) relatively new, b) there's in-core development of extensions, and pgq isn't exactly trivial, partially written in python, ...
В списке pgsql-hackers по дате отправления: