On 2024-Dec-13, Önder Kalacı wrote:
> Matheus Alcantara <matheusssilv97@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/
