On 23.03.21 00:18, Tom Lane wrote:
However, ParseNamespaceItem as it stands needs some help for this.
It has a wired-in assumption that p_rte->eref describes the table
and column aliases exposed by the nsitem. 0001 below fixes this by
creating a separate p_names field in an nsitem. (There are some
comments in 0001 referencing JOIN USING aliases, but no actual code
for the feature.) That saves one indirection in common code paths,
so it's possibly a win on its own. Then 0002 is your patch rebased
onto that infrastructure, and with some cleanup of my own.
Makes sense. I've committed it based on that.
Speaking of decompiled views, I feel like ruleutils.c could do with
a little more work to teach it that these aliases are available.
Right now, it resorts to ugly workarounds:
Yeah, the whole has_dangerous_join_using() can probably be unwound and
removed with this. But it's a bit of work.
One other cosmetic thing is that this:
regression=# select tu.* from (t1 join t2 using(a) as tu) tx;
ERROR: missing FROM-clause entry for table "tu"
LINE 1: select tu.* from (t1 join t2 using(a) as tu) tx;
^
is a relatively dumb error message, compared to
regression=# select t1.* from (t1 join t2 using(a) as tu) tx;
ERROR: invalid reference to FROM-clause entry for table "t1"
LINE 1: select t1.* from (t1 join t2 using(a) as tu) tx;
^
HINT: There is an entry for table "t1", but it cannot be referenced from this
part of the query.
I didn't look into why that isn't working, but maybe errorMissingRTE
needs to trawl all of the ParseNamespaceItems not just the RTEs.
Yes, I've prototyped that and it would have the desired effect. Might
need some code rearranging, like either change searchRangeTableForRel()
to not return an RTE or make a similar function for ParseNamespaceItem
search. Needs some more thought. I have left a test case in that would
show any changes here.
