I don't think so. What do you need it for if I may ask? If some people actually need a patch it is much more likely to get people working on it to make it committable.
fwiw, we have a team working on OrioleDB at supabase, with the plan to get to GA later this year or early next year. we'll continue to submit patches upstream for the TAM, and of course that will take as long as it takes for the community to accept them. Our focus right now reliability and compatibility, so that the community can gain confidence in the implementation
I was wondering how far away OrioleDB was from becoming a pure extension instead of being a postgres fork. I'm not an expert by any means on TAM - but was curious if the Orioledb team managed to upstream some parts of their fork.
Most alternative PG storage engines have stumbled, and OrioleDB touches a lot of core surfaces.
The sensible order is: first make OrioleDB rock-solid and bug-free; ( https://github.com/orioledb/orioledb/issues?q=is%3Aissue%20s... ) then, using real-world feedback and perf data, refactor and carve out patches that are upstream-ready. That’s a big lift for both the OrioleDB team and core PG.
From what I understand, they’re aiming for a release candidate in the next ~6 months; meaningful upstreaming would come after that.
In other words: make it work --> validate the plan --> upstream the final patches.
