From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Nunya Business" <nb3425586@gmail.com>
cc: pgsql-general@postgresql.org
Subject: Re: PG 14.5 -- Impossible to restore dump due to interaction/order of
 views, functions, and generated columns
In-reply-to: <emad8fa821-2230-4b8b-893b-cb2b8b376e9b@81da44b0.com>
References: <emad8fa821-2230-4b8b-893b-cb2b8b376e9b@81da44b0.com>
Comments: In-reply-to "Nunya Business" <nb3425586@gmail.com>
	message dated "Mon, 05 Dec 2022 19:49:40 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3635233.1670340237.1@sss.pgh.pa.us>
Date: Tue, 06 Dec 2022 10:23:57 -0500
Message-ID: <3635234.1670340237@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3635234.1670340237%40sss.pgh.pa.us>
Precedence: bulk

"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