On Thu, Nov 7, 2024 at 2:05 AM Peter Eisentraut <pe...@eisentraut.org> wrote: > On 06.11.24 20:06, Robert Haas wrote: > > I can make nothing of*TLOCRN* or*TROCRN*, even > > after looking at the relevant source code, > > These are from the SQL standard text. So they are more guidance to the > implementer than anything else. I think something had to be put there, > because erefs are required. I'm also interested in the discussion you > raise about that. > > (I think they are meant to be something like "table {left|right} operand > cycle reference name".)
Interesting. I guess we could maybe document that a bit better, but it's not the main thing to focus on. I tried replacing all of those fake RTE entry names with NULL and fixing whatever broke in the regression tests. I attach the result. It seems like this is basically a problem that applies to subqueries rather than any other form of RTE, and mostly subqueries that are named *SELECT* or *SELECT* %d. The main place where the names are user-visible in EXPLAIN output. With this patch, the name displayed by EXPLAIN changed to unnamed_subquery, but that's what we already use for subqueries in some cases, so I don't see a problem with it. There's one case where *SELECT* 2 actually showed up in an error message. I chose to add a second variant of the message rather than displaying the name as unnamed_subquery, but either could be done: -DETAIL: There is a column named "q2" in table "*SELECT* 2", but it cannot be referenced from this part of the query. +DETAIL: There is a column named "q2", but it cannot be referenced from this part of the query. It's quite possible that this patch isn't completely correct and it's also possible that I'm missing some deeper problem with this idea that just isn't exercised by the regression tests. But overall I find these results fairly encouraging -- it just wasn't very hard to make the regression tests pass. I did a bit of historical checking at the comment that eref->aliasname is required to be present was added in commit 3a94e789f5c9537d804210be3cb26f7fb08e3b9e, Tom Lane, 2000. I can't immediately tell what the reasoning was. Copying Tom in case he has thoughts. -- Robert Haas EDB: http://www.enterprisedb.com