Re: The output sql generated by pg_dump for a create function refers to a modified table name

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: The output sql generated by pg_dump for a create function refers to a modified table name
Дата
Msg-id 2769963.1676666791@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: The output sql generated by pg_dump for a create function refers to a modified table name  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Список pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 2/17/23 1:18 PM, Tom Lane wrote:
>> It can be reproduced with INSERT too, on the same principle as the others:
>> put the DML command inside a WITH, and give it an alias conflicting with
>> the outer query.

> Ah, I see based on your example below. I did not alias the INSERT 
> statement in the way (and I don't know how common of a pattern it is to 
> o that).

I suppose you can also make examples where the true name of the DML
target table conflicts with an outer-query name, implying that we need
to give it an alias even though the user wrote none.

> I tested this against HEAD (+v69 of the DDL replication patch). My cases 
> are now all passing.
> The code looks good to me -- I don't know if moving that logic is 
> overkill, but it makes the solution relatively clean.

Cool, thanks for testing and code-reading.  I'll go see about
back-patching.

> I didn't test in any back branches yet, but given this can generate an 
> invalid function body, it does likely need to be backpatched.

Presumably it can also cause dump/restore failures for rules that
do this sort of thing, though admittedly those wouldn't be common.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Move defaults toward ICU in 16?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Move defaults toward ICU in 16?