Re: pg_upgrade is failed for 'plpgsql_call_handler' handler

> On 3 Jun 2021, at 16:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 3 Jun 2021, at 11:53, tushar <tushar(dot)ahuja(at)enterprisedb(dot)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/