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

From Daniel Gustafsson
Subject Re: pg_upgrade is failed for 'plpgsql_call_handler' handler
Date
Msg-id B1946B73-973E-4327-9CF8-FBD5573C40D0@yesql.se
Whole thread Raw
In response to pg_upgrade is failed for 'plpgsql_call_handler' handler  (tushar <tushar.ahuja@enterprisedb.com>)
Responses Re: pg_upgrade is failed for 'plpgsql_call_handler' handler  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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 isn't really a pg_upgrade issue but a pg_dump issue.  The handler, inline
nd validator functions will be looked up among the functions loaded into
pg_dump and included in the CREATE LANGUAGE statement.  However, iff they are
in pg_catalog then they wont be found (pg_catalog is excluded in getFuncs) and
a bare CREATE LANGUAGE statement will be emitted.  This bare statement will
then be interpreted as CREATE EXTENSION.

This is intentional since the language template work in 8.1, before then
pg_dump would look up support functions in pg_catalog.

--
Daniel Gustafsson        https://vmware.com/




pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Are we missing (void) when return value of fsm_set_and_search is ignored?
Next
From: Dilip Kumar
Date:
Subject: Re: Are we missing (void) when return value of fsm_set_and_search is ignored?