On Mon, Dec 16, 2019 at 12:00 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > What I'd like, in order to make progress with the planner rewrite, > is that all four Vars in the tlist have varno 3, showing that > they are (potentially) semantically distinct from the Vars in > the JOIN ON clause (which'd have varnos 1 and 2 in this example). > > This is a pretty small change as far as most of the system is > concerned; there should be noplace that fails to cope with a > join alias Var, since it'd have been legal to write a join > alias Var in anyplace that would change.
I don't have an opinion about the merits of this change, but I'm curious how this manages to work. It seems like there would be a fair number of places that needed to map the join alias var back to some baserel that can supply it. And it seems like there could be multiple levels of join alias vars as well, since you could have joins nested inside of other joins, possibly with subqueries involved. At some point I had the idea that it might make sense to have equivalence classes that had both a list of full members (which are exactly equivalent) and nullable members (which are either equivalent or null). I'm not sure whether that idea is of any practical use, though. It does seems strange to me that the representation you are proposing gets at the question only indirectly. The nullable version of the Var has got a different varno and varattno than the non-nullable version of the Var, but other than that there's no connection between them. How do you go about matching those together? I guess varnoold/varoattno can do the trick, but if that's only being used by ruleutils.c then there must be some other mechanism. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
