3 ms·

> OrioleDB ... solving some PostgreSQL wicked problems Why was Postgres forked? I don't want this to come across as negative towards Postgres (or discouraging

> OrioleDB ... solving some PostgreSQL wicked problems Why was Postgres forked? I don't want this to come across as negative towards Postgres (or discouraging toward Alexander) but given that these fixes aren't upstream in Postgres - developed by a known/respected contributor, is this indicative to some type of politics / infighting happening within the Postgres community on the architectural direction of their (amazing) database? I see some comments in this thread touch a little on this topic but why does this need to wait 2-3 release cycles before it's upstreamed to Postgres? That's going to be roughly 4 years from now.

salmo 5y ago
It’s not a fork. It’s an extension. That’s both in the doc and build instructions. That is a very appropriate way to run ahead and add experimental features that could be folded in later, even just later maintaining the extension as part of the OOB release. It speaks to the architecture of Postgres that this is possible to implement this way. I would love to see this be successful. Much cleaner than stacking software in front of and around Postgres, and not just a wire-compatible DB like Cockroach.
akorotkov 5y ago
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.

salmo 5y ago

It’s not a fork. It’s an extension. That’s both in the doc and build instructions. That is a very appropriate way to run ahead and add experimental features that could be folded in later, even just later maintaining the extension as part of the OOB release. It speaks to the architecture of Postgres that this is possible to implement this way. I would love to see this be successful. Much cleaner than stacking software in front of and around Postgres, and not just a wire-compatible DB like Cockroach.

akorotkov 5y ago

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.