Bumping this discussion again. We haven't enabled the pxf_fdw in our daily development for more than 10 months [1]; that is, nobody will maintain it anymore.
For the next, I think: - we can remove the `pxf_fdw` from the core - Split the `apache/cloudberry-pxf` packages into `pxf-server`, `pxf-cli`, and `pxf-fdw`, following the way in greengage-pxf[2] [1] https://github.com/apache/cloudberry/commit/eb0f1cc50db70d2720a14fd1a657600e22708bb4 [2] https://github.com/GreengageDB/pxf/commit/38a9ce6af390404b2c30590891d68837488a52cb Best, Dianjin Wang On Wed, Oct 22, 2025 at 4:13 PM Nikolai Antonov <[email protected]> wrote: > > Hi! > > From my point of view, moving C/C++ code to apache/cloudberry may have > several benefits: > * it greatly simplify build workflow for apache/cloudberry-pxf (no need to > have C++ toolchain installed) > * vmware PXF 7.0 supports External PXF Clusters[1]. Probably, cloudberry-pxf > may want to support > independent scaling or even on-demand "serverless PXF". In this case it > will be more convenient > to have separate RPMs/DEBs for extension and for java PXF server. Then it > is reasonable to merge > extension to apache/cloudberry. > > Also, moving code to apache/cloudberry have cons: > * it will require to keep cloudberry and cloudberry-pxf compatible on API > level. > > [1] > https://techdocs.broadcom.com/us/en/vmware-tanzu/data-solutions/tanzu-greenplum-platform-extension-framework/7-0-0/gp-pxf/deployment_topos.html > > Best regards, > Nikolay Antonov --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
