Re: Maliing list request: pgsql-forks@

>
>
>
> So when somebody wants to do some core changes in your company, they
> never discuss it with their colleagues before posting to -hackers?
>
>
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.

- help each other using hooks/apis when there does not seem to be
> straightforward way of doing something (this does not belong to -hackers
> IMHO and there is no other C level hacker mailing list)
>

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.

https://wiki.postgresql.org/wiki/Todo:HooksAndTracePoints

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.

> - do initial discussion on ideas for extensibility enhancements of
> PostgreSQL - it does help to know what you are proposing is useful for
> others or that it can be ironed out to be more broadly useful
>

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:

https://wiki.postgresql.org/wiki/PostgresServerExtensionPoints

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.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise