Re: Allow FDW extensions to support MERGE command via CustomScan

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Önder Kalacı <onderkalaci(at)gmail(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow FDW extensions to support MERGE command via CustomScan
Date: 2024-12-13 11:04:33
Message-ID: 202412131104.ch4ogwcbr3ml@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-Dec-13, Önder Kalacı wrote:

> Matheus Alcantara <matheusssilv97(at)gmail(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Kositsin 2024-12-13 11:21:45 Re: [PATCH] Fixed creation of empty .log files during log rotation
Previous Message Nisha Moond 2024-12-13 11:00:27 Re: Introduce XID age and inactive timeout based replication slot invalidation