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 по дате отправления: