Re: Maliing list request: pgsql-forks@

Greetings,

* Nasby, Jim (nasbyj(at)amazon(dot)com) wrote:
> 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.

There seems to me, anyway, to be an even smaller set of extensions that
*aren't* at the C level, so I don't really buy off on this argument.
-extensions seems like a good name to me.

> 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

If you manage to succeed in addressing this, I think we would all be the
worse off for it. I certainly don't think it's the purview of some
relatively minor list to try and influence that...

> Forks can break extension compatibility

That's kind of a "don't do that" on the part of the forks, isn't it..?
Or, at least accept it when you do. ;)

> Backend static functions / structs

I'd love to see more capability available through the common library for
inspecting things with both core tools (i.e. pg_controldata, pg_waldump)
and for external tools to leverage. One of the big challenges here is
that we don't currently have any idea of multi-version support, even
though a lot of external tools deal with multiple versions and therefore
end up writing their own. Having that done in the common library would
allow those external tools to leverage it, along with tools like
pg_controldata.

This should really be discussed on -hackers though.

> 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)

Should all be discussed on -hackers...

> Still too much is_superuser() (possibly also broader)

This should be discussed on -hackers (and feel free to CC me, given my
personal vendetta against is_superuser()...).

Thanks,

Stephen