On 4/8/21 8:13 AM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>> Can we move forward with this?
>
>> We could just push the change and see what happens. But I was thinking
>> more in terms of doing that early in the v15 cycle. I remain skeptical
>> that we need a near-term fix.
>
> To make sure we don't forget, I added an entry to the next CF for this.
Thanks for your efforts.
I tried to dive deeper: replace ROWID_VAR with -4 and explicitly change
types of varnos in the description of functions that can only work with
special varnos.
Use cases of OUTER_VAR looks simple (i guess). Use cases of INNER_VAR is
more complex because of the map_variable_attnos(). It is needed to
analyze how negative value of INNER_VAR can affect on this function.
INDEX_VAR causes potential problem:
in ExecInitForeignScan() and ExecInitForeignScan() we do
tlistvarno = INDEX_VAR;
here tlistvarno has non-negative type.
ROWID_VAR caused two problems in the check-world tests:
set_pathtarget_cost_width():
if (var->varno < root->simple_rel_array_size)
{
RelOptInfo *rel = root->simple_rel_array[var->varno];
...
and
replace_nestloop_params_mutator():
if (!bms_is_member(var->varno, root->curOuterRels))
I skipped this problems to see other weak points, but check-world
couldn't find another.
--
regards,
Andrey Lepikhov
Postgres Professional
