From my point of view, PostgreSQL development is quite conservative. Every small change may become a subject of heated debates, nothing to say about big changes. This approach to the development have advantages and disadvantages.
But if we imagine OrioleDB accepted to the upstream, that would be most dramatical changes since PostgreSQL was released to Open Source. This is why I decided to make a fork and then merge it to upstream step-by-step.
It's not that bad to use a fork during 2-3 release cycles give that:
1) It's not highly divergent fork (the patchset is small).
2) They patchset will be smoothly decrease over that period of time.
Also, even 2-3 release cycles isn't that bad in comparison with decades while we have small progress in wicked problems.
It's not that bad to use a fork during 2-3 release cycles give that: 1) It's not highly divergent fork (the patchset is small). 2) They patchset will be smoothly decrease over that period of time. Also, even 2-3 release cycles isn't that bad in comparison with decades while we have small progress in wicked problems.