pg_upgrade is failed for 'plpgsql_call_handler' handler
Hi,
In one of my testing scenario, i found pg_upgrade is failed for
'plpgsql_call_handler' handler
Steps to reproduce - ( on any supported version of PG)
Perform initdb ( ./initdb -D d1 ; ./initdb -D d2)
Start d1 cluster(./pg_ctl -D d1 start) , connect to postgres (./psql
postgres) and create this language
postgres=# CREATE TRUSTED LANGUAGE plspl_sm HANDLER plpgsql_call_handler;
CREATE LANGUAGE
stop the server (./pg_ctl -D d1 stop)
perform pg_upgrade ( ./pg_upgrade -d d1 -D d2 -b . B .)
will fail with these message
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 825; 2612 16384 PROCEDURAL LANGUAGE plspl_sm edb
pg_restore: error: could not execute query: ERROR: could not open
extension control file
"/home/edb/pg14/pg/edbpsql/share/postgresql/extension/plspl_sm.control":
No such file or directory
Command was: CREATE OR REPLACE PROCEDURAL LANGUAGE "plspl_sm";
is this expected ?
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company
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/
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
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' handleThis 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/