On Tue, Aug 20, 2024 at 09:05:54AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
>> too.
>
> +1. I think the fmgr.h prototype may have been left there
> deliberately to avoid breaking extension code, but it's past
Heikki Linnakangas writes:
> On 20/08/2024 07:46, Michael Paquier wrote:
>> How about removing it like in the attached to be consistent?
> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
> too.
+1. I think the fmgr.h prototype may have been left there
deliberately to a
On Tue, Aug 20, 2024 at 09:59:12AM +0300, Heikki Linnakangas wrote:
> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
> too.
Yes, I was wondering too whether we should force the hand of
extensions to know that it is pointless to support unloading, telling
everybody to dele
On 20/08/2024 07:46, Michael Paquier wrote:
Hi all,
While hacking on a different thing, I've noticed that
ldap_password_func had the idea to define _PG_fini(). This is
pointless, as library unloading is not supported in the backend, and
something that has been cleaned up from the tree in ab02d7
Hi all,
While hacking on a different thing, I've noticed that
ldap_password_func had the idea to define _PG_fini(). This is
pointless, as library unloading is not supported in the backend, and
something that has been cleaned up from the tree in ab02d702ef08.
That's not something to encourage, per
