Re: Maliing list request: pgsql-forks@

> On Jul 30, 2019, at 10:14 AM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 30 Jul 2019, at 16:35, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>>
>>> On Jul 30, 2019, at 06:42, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>>>
>>> (and while I do like blue for the color of the bike ;) I think that
>>> "distributions" is too close to "packaging" and could be confusing.
>>>
>>> Why I suggested "-extensions" is that it appears to be inclusive of
>>> things that augment PostgreSQL abilities, be they actual PG extensions
>>> or forks.
>>
>> +1 for "-extensions" over "-distributions". An extension generally doesn't imply an entire distribution. When I first saw "-distributions", my thought was, "Don't we have that list already?”
>
> Fair enough. As long as we paint it a color, regardless of which, I’m happy to
> park there.

My concern about calling this -extensions is that it’s really meant for people that are at least at the level of C extensions (and probably only those making use of hooks). That’s a relatively small number of extensions, even if they are some of the most important extensions.

Maybe paint it “-binary”? -internals might work too.

In case it adds some better perspective, here’s the list of pain points that were captured in the BoF:

Pain for forks due to high velocity of upstream commits
Forks can break extension compatibility
PG DLL import
Backend static functions / structs
Not enough hooks
Ordering of hook registration
More pluggable modules/components
Extension upgrading is difficult
Not enough test coverage for hooks
Hard to extend grammar (add more WITH options?)
Improvements to typmodin()
Problems with extensions calling other extensions (both SQL and C; this item is actually broader than the others)
Still too much is_superuser() (possibly also broader)