On 28/10/2024 20:19, Ashutosh Bapat wrote:
> 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.
My goal is to understand why the implementation follows this pattern. As
I see, previously, we had consistent behaviour, according to which we
removed the pulling-up subquery's alias as well. And I want to know, is
it really the only way to break this behavior? Maybe it is possible to
add the VALUES alias to the grammar. Or is it causing much worse code?
--
regards, Andrei Lepikhov
