On 12/13/24 16:03, Önder Kalacı wrote:
> 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 d
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
On 2024-Dec-13, Önder Kalacı wrote:
> Matheus Alcantara 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 i
HI Matheus, all
>
> > +
> > +
> > + Postgres doesn't support MERGE on foreign tables,
> > + see ExecMerge. Still, extensions may provide
> > + custom scan nodes to support MERGE on foreign
> > + tables. If your extension provides such custom scan node, this
> > + function shoul
Hi,
Just some thoughts on documentation part.
+
+
+ Postgres doesn't support MERGE on foreign tables,
+ see ExecMerge. Still, extensions may provide
+ custom scan nodes to support MERGE on foreign
+ tables. If your extension provides such custom scan node, this
+ function sh
Hi hackers,
Currently, it is not possible for any fdw extension to support Merge
command, as that's prohibited in the parser.
In this proposal, we allow extensions to support Merge command via
`CustomScan` node by moving the Merge support check from parser to planner.
For existing fdw, they don'
