On Mon, Oct 28, 2024 at 10:17 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> On 10/28/24 03:15, Yasir wrote:
> > By design of my solution, I was not taking it as a bug. But now, I agree
> > with your opinion.
> I think the case provided by Ashutosh was initially correct, and nothing
> needs to change. Look at the similar case:
>
> EXPLAIN SELECT x,y FROM (
> SELECT oid,relname FROM pg_class WHERE relname = 'pg_index') AS
> c(x,y) WHERE c.y = 'pg_index';
>
> QUERY PLAN
>
> --------------------------------------------------------------------------------------------
> Index Scan using pg_class_relname_nsp_index on pg_class
> (cost=0.27..8.29 rows=1 width=68)
> Index Cond: (relname = 'pg_index'::name)
> (2 rows)
>
> I don't see any reference to the alias c(x,y) in this explain.
> Similarly, the flattened VALUES clause shouldn't be referenced under the
> alias t(a,b).
The reason you don't see c(x, y) is because the subquery gets pulled
up and the subquery with c(x, y) no longer exists. If the subquery
doesn't get pulled, you would see c(x, y) in the EXPLAIN plan.
Our syntax doesn't allow an alias to be attached to VALUES(). E.g.
select * from values (1), (2) x(a) is not allowed. Instead we allow
(values (1), (2)) x(a) where values (1), (2) is treated as a subquery.
Since there is no way to attach an alias to VALUES() itself, I think
it's fair to consider the outer alias as the alias of the VALUES
relation. That's what Tom's patch does. The result is useful as well.
The patch looks good to me, except the name of the new member.
CommonTableExpr *p_parent_cte; /* this query's containing CTE */
+ Alias *p_parent_alias; /* parent's alias for this query */
the two "parent"s here mean different things and that might lead one
to assume that the p_parent_alias refers to alias of CTE. The comment
adds to the confusion since it mentions parent. How about renaming it
as p_outer_alias? or something which indicates alias of the outer
query?
--
Best Wishes,
Ashutosh Bapat
