Re: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns
От | Tom Lane |
---|---|
Тема | Re: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns |
Дата | |
Msg-id | 3635234.1670340237@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns ("Nunya Business" <nb3425586@gmail.com>) |
Ответы |
Re[2]: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns
Re[2]: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns |
Список | pgsql-general |
"Nunya Business" <nb3425586@gmail.com> writes: > Within my schema there is a table that has a GENERATED ALWAYS column > that calls a plpgsql function. The called function has a "row type" > variable declared that references a view. While the schema itself > functions properly day to day, and pg_dumpall works as expected, the > generated SQL fails to successfully execute. The table in question is > restored with no rows, and an error is generated during the COPY stating > that the type does not exist. Hmm, do you have actually circular dependencies in that? pg_dump has some heuristics for dealing with such cases, but maybe it needs more. Please create a self-contained example and submit it to pgsql-bugs. regards, tom lane
В списке pgsql-general по дате отправления: