On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> On 2/6/21 02:32, Tom Lane wrote:
> > I wrote:
> >> I think a preferable fix involves making sure that the correct
> >> record-type typmod is propagated to record_in in this context.
> >> Alternatively, maybe we could insert the foreign table's rowtype
> >> during execution of the input operation, without touching the
> >> plan as such.
> >
> > Here's a draft-quality patch based on that idea. It resolves
> > the offered test case, but I haven't beat on it beyond that.
> >
> I played with your patch and couldn't find any errors. But what if ROW
> operation were allowed to be pushed to a foreign server?
>
> Potentially, I can imagine pushed-down JOIN with arbitrary ROW function
> in its target list.
Are you saying that a pushed down ROW() expression may not correspond
with the Var chosen by the following code?
+ /*
+ * If we can't identify the referenced table, do nothing. This'll
+ * likely lead to failure later, but perhaps we can muddle through.
+ */
+ var = (Var *) list_nth_node(TargetEntry, fsplan->fdw_scan_tlist,
+ i)->expr;
+ if (!IsA(var, Var))
+ continue;
+ rte = list_nth(estate->es_range_table, var->varno - 1);
+ if (rte->rtekind != RTE_RELATION)
+ continue;
+ reltype = get_rel_type_id(rte->relid);
+ if (!OidIsValid(reltype))
+ continue;
+ att->atttypid = reltype;
That may be a valid concern. I wonder if it would make sense to also
check varattno == 0 here somewhere for good measure.
--
Amit Langote
EDB: http://www.enterprisedb.com
