Re: [DISCUSS] Cloudberry and cloudberry-pxf both have pxf_fdw and external_table. Which one should we prioritize?

[Dianjin Wang <wa...@gmail.com>]

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 <os...@yandex-team.ru> 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: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org