On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov <a.lepik...@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
