From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade is failed for 'plpgsql_call_handler' handler |
Date: | 2021-06-03 14:12:06 |
Message-ID: | 273102.1622729526@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-06-03 14:20:10 | Re: pg_upgrade is failed for 'plpgsql_call_handler' handler |
Previous Message | Tom Lane | 2021-06-03 13:45:35 | Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) |