Re: Maliing list request: pgsql-forks@

Exactly.  Or even build the whole feature for a customer and deliver it before trying to upstream the functionality in the next community release, for that matter.

That happens whether it's a solo developer or a team in a company. Letting people with common interests find out about work earlier and potentially make suggestions to help it meet their needs too and/or make it more likely to be acceptable upstream seems unlikely to be a bad thing.

It won't stop anyone going off and writing something that meets their immediate needs and is utterly unsuitable for upstream. But they can already do that now.

In fact I'd argue that given how Pg development works, people are often almost required to write it first anyway. Everyone's so busy that it can be very hard to get attention from key stakeholders on early design discussions or prototype work, so often one must develop a believable implementation of a feature and add it to a CF before it gets much attention. At that point as often or not the original developer may be told "that's an awful way to do it, you can't do that because of X, go do it $otherway instead," so they go scrap their work and start again. There aren't any easy ways to prevent that really as it's a pretty natural evolution of the development process, communication style and decision making approach used in the community. We don't really have "subsystem owners" or anything and most key devs can effectively veto something, but we have too much being developed to let everyone who might object examine the initial design instead of a much quicker and easier to study concrete testable implementation.

I don't actually much care if this list is created or not, though if it's not I'd like to see more active discussion of addins/forks/extensions/etc encouraged on hackers proper. I very much do care about improving collaboration between the companies and teams working on extensions to reduce wasted work and to make the core of postgres more extensible and pluggable.

Absolutely.

I scratched out a wiki page to start on this by the way. I will link it from the main TODO wiki page soon. The goal is to let people get together and identify common sets of needs for hooks/callbacks/tracepoints/plugin APIs/etc so that they can be added in an organised manner.

I've copied my existing notes on the tracepoints and accounting I want to add for logical decoding and the walsender as a starting point.

 

Yep, or if someone else already solved it in a way that doesn't require core changes in the first place. There is so much of PostgreSQL that you just have to know about because we don't have much in the way of overview documentation on extending PostgreSQL at a scale beyond writing C functions.

I started some notes on that too with the intention of helping out people who're getting on board with extension development or joining teams that work on complex extensions. At some point I'd like to tidy these notes and add them to the core docs in the extending the server section but I'll be unlikely to find the time to organise, xref and DocBook-ify them any time soon so for now they're in a wiki too:

I need to dig up Andres's old notes on how logical decoding works internally and a few other things to try to merge into that and/or the main docs too, but that'll have to wait until a lull in my main development priorities.