Re: Deparsing rewritten query

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Gilles Darold <gilles(at)darold(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Deparsing rewritten query
Date: 2022-02-01 19:35:00
Message-ID: CAFj8pRBXJ=kGy-=AYk8prpHS-Kff8E6aKWvg_3jWbzQ_Sb50uA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 1. 2. 2022 v 4:38 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-02-01 20:02:38 Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?
Previous Message Fabien COELHO 2022-02-01 19:25:50 Re: Latest LLVM breaks our code again