Re: Deparsing rewritten query - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Deparsing rewritten query
Date
Msg-id CAFj8pRBXJ=kGy-=AYk8prpHS-Kff8E6aKWvg_3jWbzQ_Sb50uA@mail.gmail.com
Whole thread Raw
In response to Re: Deparsing rewritten query  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Deparsing rewritten query  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers


út 1. 2. 2022 v 4:38 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
Hi,

On Mon, Jan 31, 2022 at 10:05:44PM +0100, Pavel Stehule wrote:
>
> I don't feel good about forcing an alias. relname doesn't ensure
> uniqueness. You can have two views with the same name from different
> schemas. Moreover this field is necessary only when a deparsed query is
> printed, not always.

Yes I agree.

> Isn't possible to compute the correct subquery alias in print time when it
> is missing?

Actually I think that the current code already does everything to generate
unique refnames, it's just that they don't get printed for a query after view
expansions.  I modified the patch to simply make sure that an alias is
displayed when it's a subquery and the output using a custom pg_get_query_def
is like that:

# select  pg_get_query_def('select * from nsp1.v1');
       pg_get_query_def
-------------------------------
  SELECT nb                   +
    FROM ( SELECT 1 AS nb) v1;+

(1 row)


# select  pg_get_query_def('select * from nsp1.v1, nsp2.v1');
       pg_get_query_def
-------------------------------
  SELECT v1.nb,               +
     v1_1.nb                  +
    FROM ( SELECT 1 AS nb) v1,+
     ( SELECT 1 AS nb) v1_1;  +

(1 row)

I tested your patch, and it looks so it is working without any problem. All tests passed.

There is just one question. If printalias = true will be active for all cases or just with some flag?

I didn't find any visible change of this modification without your function, so maybe it can be active for all cases without any condition.

Regards

Pavel



 

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Latest LLVM breaks our code again
Next
From: David Rowley
Date:
Subject: Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?