On 2024-Dec-13, Önder Kalacı wrote: > Matheus Alcantara <matheusssil...@gmail.com> wrote:
> > I didn't understand what is a "custom scan node" on the fdw context at > > first place (I don't know if it is an already know word on this > > context), but from what I've understood so far, to a fdw extension > > support MERGE it should implements on PlanForeignModify right? > > In the long term, I think that's a good plan. First, the core code in > ExecMerge() should be aware of foreign tables, then each foreign table > should handle Merge command planning on its own PlanForeignModify. > That'd be great, because the execution of Merge command is pretty > complex, and in essence Postgres would be providing the solid > infrastructure for all foreign tables. > > However, I expect that to be a non-trivial patch. Instead, the goal of > this patch is to at least let extensions to completely override the > planning & execution via CustomScan, not confined to Postgres' foreign > table planning & execution. IMO this is a bad plan. It'll become _the_ way to run MERGE on foreign tables, which will become a selling point for proprietary FDWs, and nobody will be motivated to write the code to implement the long-term plan you were describing. In short, -1 from me. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
