Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1
Date
Msg-id 1948671.1686748004@sss.pgh.pa.us
Whole thread Raw
In response to Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> I just realized that we may still have holes in this area.  Until now
> we're mainly focusing on LATERAL subquery, in which case the lateral
> reference Vars are copied into rel->subplan_params and we've already
> adjusted the nulling bitmaps there.  But what about the lateral
> reference Vars in other cases?

Ugh.

> So it seems that we need to do nullingrel adjustments in a more common
> place.

I agree: this suggests that we fixed it in the wrong place.

> I think it exposes a new issue.  It seems that we extract a problematic
> lateral_relids from lateral references within PlaceHolderVars in
> create_lateral_join_info.  I doubt that we should use ph_lateral
> directly.  It seems more reasonable to me that we strip outer-join
> relids from ph_lateral and then use that for lateral_relids.

Hmm.  I don't have time to think hard about this today, but this
does feel similar to our existing decision that parameterized paths
should be generated with minimal nullingrels bits on their outer
references.  We only thought about pushed-down join clauses when we
did that.  But a lateral ref necessarily gives rise to parameterized
path(s), and what we seem to be seeing is that those need to be
handled just the same as ones generated by pushing down join clauses.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Do we want a hashset type?
Next
From: Tomas Vondra
Date:
Subject: Re: Do we want a hashset type?