On Mon, May 11, 2020 at 8:58 AM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > What happens if there's a mixture of foreign and local partitions or > mixture of FDWs? Injecting junk columns from all FDWs in the top level > target list will cause error because those attributes won't be > available everywhere.
I think that we're talking about a plan like this: Update -> Append -> a bunch of children I believe that you'd want to have happen here is for each child to emit the row identity columns that it knows about, and emit NULL for the others. Then when you do the Append you end up with a row format that includes all the individual identity columns, but for any particular tuple, only one set of such columns is populated and the others are all NULL. There doesn't seem to be any execution-time problem with such a representation, but there might be a planning-time problem with building it, because when you're writing a tlist for the Append node, what varattno are you going to use for the columns that exist only in one particular child and not the others? The fact that setrefs processing happens so late seems like an annoyance in this case. Maybe it would be easier to have one Update note per kind of row identity, i.e. if there's more than one such notion then... Placeholder -> Update -> Append -> all children with one notion of row identity -> Update -> Append -> all children with another notion of row identity ...and so forth. But I'm not sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
