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