Re: Allow FDW extensions to support MERGE command via CustomScan

From: Önder Kalacı <onderkalaci(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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 15:03:31
Message-ID: CACawEhXnYtEBhQua7r+F0xLKWCXZc6-Vib68dXCA20mQs+WbPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro, all

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

I see your point, but this seems like an artificial limitation in Postgres.
The parser usually doesn’t impose such restrictions, so it’s hard to
understand why FDWs should be treated differently. If someone really wanted
to work around this today, they could hack Postgres and avoid the
limitation anyway.

Our goal here is to follow the spirit of custom scans: enable
experimentation and see what works. This approach doesn’t close the door to
a more complete, native implementation later—it just creates a more natural
path forward in the meantime.
Thanks,
Onder

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-12-13 15:30:22 Re: Recovering from detoast-related catcache invalidations
Previous Message Vitaly Davydov 2024-12-13 14:34:01 Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly