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/
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 |