Re: Making the subquery alias optional in the FROM clause - Mailing list pgsql-hackers

From Erwin Brandstetter
Subject Re: Making the subquery alias optional in the FROM clause
Date
Msg-id CAGHENJ6MUCdJxoh3mebMnJk4w1N_-VJM_kXPA3dcS=YD+t3ytg@mail.gmail.com
Whole thread Raw
In response to Making the subquery alias optional in the FROM clause  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Making the subquery alias optional in the FROM clause
List pgsql-hackers

On Mon, 2 Oct 2023 at 00:33, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
The only place that exposes the eref's made-up relation name is the
existing query deparsing code in ruleutils.c, which uniquifies it and
generates SQL spec-compliant output. For example:

I ran into one other place: error messages.

SELECT unnamed_subquery.a
FROM (SELECT 1 AS a)

> ERROR:  There is an entry for table "unnamed_subquery", but it cannot be referenced from this part of the query.invalid reference to FROM-clause entry for table "unnamed_subquery"

Normally, we would find the cited name somewhere in the query. Confusing.
Notably, the same does not happen for "unnamed_subquery_1":

SELECT unnamed_subquery_1.a
FROM (SELECT 1 AS a), (SELECT 1 AS a)

> ERROR:  missing FROM-clause entry for table "unnamed_subquery_1"

That's the message anybody would expect.
Also makes sense, as "uniquification" only happens in the above quoted case, and all invisible aliases seem to be "unnamed_subquery" at this point? But a bit confusing on a different level.

Maybe error messages should not be aware of invisible aliases, and just complain about "missing FROM-clause entry"?
Not sure whether a fix would be easy, nor whether it would be worth the effort. Just wanted to document the corner case issue in this thread.

Regards
Erwin

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pgstatindex vs. !indisready
Next
From: "Karl O. Pinc"
Date:
Subject: Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector