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.

▲

ksec a day ago | parent | next [-]

TAM is prerequisite for OrioleDB. And I am guessing OP like me is looking forward to orioledb being used as default or even upstreamed.

▲

jeltz 16 hours ago | parent [-]

OrioleDB is very far from being usable as default or upstreamed. Nobody is working on this right now.

	▲	kiwicopple 5 hours ago \| parent [-]
		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

▲

sudarshnachakra 20 hours ago | parent | prev [-]

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.

	▲	pella 16 hours ago \| parent [-]
		imho: not soon. 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.