Re: Deparsing rewritten query
| От | Julien Rouhaud |
|---|---|
| Тема | Re: Deparsing rewritten query |
| Дата | |
| Msg-id | 20220201033707.facusnf6evjmnoo3@nol обсуждение исходный текст |
| Ответ на | Re: Deparsing rewritten query (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: Deparsing rewritten query
Re: Deparsing rewritten query |
| Список | pgsql-hackers |
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)
Вложения
В списке pgsql-hackers по дате отправления: