Re: pg_upgrade is failed for 'plpgsql_call_handler' handler
От | Daniel Gustafsson |
---|---|
Тема | Re: pg_upgrade is failed for 'plpgsql_call_handler' handler |
Дата | |
Msg-id | C8EA4C11-0E84-4C0E-81EB-4EBC5DBB80FB@yesql.se обсуждение исходный текст |
Ответ на | Re: pg_upgrade is failed for 'plpgsql_call_handler' handler (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> 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/
В списке pgsql-hackers по дате отправления: