> On 3 Jun 2021, at 16:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 3 Jun 2021, at 11:53, tushar <tushar.ahuja@enterprisedb.com> wrote:
>>> In one of my testing scenario, i found pg_upgrade is failed for 'plpgsql_call_handler' handle
>
>> This is intentional since the language template work in 8.1, before then
>> pg_dump would look up support functions in pg_catalog.
>
> I don't see any particular need to support reaching inside the guts
> of another PL language implementation, as this test case does.
> We'd be perfectly within our rights to rename plpgsql_call_handler
> as something else; that should be nobody's business except that
> of the plpgsql extension.
>
> But yeah, the behavior you're seeing here is intended to support
> normally-packaged languages. pg_dump won't ordinarily dump objects
> in pg_catalog, because it assumes stuff in pg_catalog is to
> be treated as built-in.
Agreed, I don't think there is anything we could/should do here (the lack of
complaints in the archives back that up).
--
Daniel Gustafsson https://vmware.com/