Re: pg_upgrade is failed for 'plpgsql_call_handler' handler - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade is failed for 'plpgsql_call_handler' handler
Date
Msg-id 273102.1622729526@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade is failed for 'plpgsql_call_handler' handler  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pg_upgrade is failed for 'plpgsql_call_handler' handler
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?)
Next
From: Daniel Gustafsson
Date:
Subject: Re: pg_upgrade is failed for 'plpgsql_call_handler' handler