| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Nunya Business" <nb3425586(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns |
| Date: | 2022-12-06 15:23:57 |
| Message-ID: | 3635234.1670340237@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-general |
"Nunya Business" <nb3425586(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2022-12-06 15:51:51 | Re: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns |
| Previous Message | Alexander Korotkov | 2022-12-05 23:57:49 | Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2022-12-06 15:51:51 | Re: PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns |
| Previous Message | Michael Loftis | 2022-12-06 15:03:34 | Re: postgres large database backup |