From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: pg_restore can't re-mat mat view that uses a function which
 depends on another mat view
In-reply-to: 
 <CAOC+FBU-2gHrbP+7QOWAbjTFP6=RGjckY7rTj80f=Rh9=+r67A@mail.gmail.com>
References: 
 <CAOC+FBU-2gHrbP+7QOWAbjTFP6=RGjckY7rTj80f=Rh9=+r67A@mail.gmail.com>
Comments: In-reply-to Wells Oliver <wells.oliver@gmail.com>
	message dated "Sun, 13 Jun 2021 15:15:59 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <162828.1623650444.1@sss.pgh.pa.us>
Date: Mon, 14 Jun 2021 02:00:44 -0400
Message-ID: <162829.1623650444@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/162829.1623650444%40sss.pgh.pa.us>
Precedence: bulk

Wells Oliver <wells.oliver@gmail.com> writes:
> Odd one here, but after restoring a database in parallel, I notice a few
> mat views are unmaterialized, e.g.
> ...
> The reason being is that vwm_ytd_p uses a function age() which queries from
> vwm_info, which has not yet been materialized. In fact, it is being
> materialized in parallel in another job, so not yet available.

Right.

> Anything to do here?

Not much we can do today.  User-defined functions are black boxes,
so pg_dump can't see what their innards might reference.

v14 will have the ability to declare SQL functions in something
closer to SQL-spec syntax, in which the body of the function will
be parsed at definition time.  With that style of function, pg_dump
*does* see the dependencies so this sort of thing should work.
That approach is not without some downsides, but it sounds like it'd
improve your case here.

			regards, tom lane