Re: New Object Access Type hooks - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: New Object Access Type hooks
Date
Msg-id 1eefe208-0262-e890-756c-6535da2109cc@dunslane.net
Whole thread Raw
In response to Re: New Object Access Type hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New Object Access Type hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: New Object Access Type hooks  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 3/22/22 13:08, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 3/22/22 12:58, Tom Lane wrote:
>>> I only suggested removing the error check in _PG_init, not
>>> changing the way the test works.
>> Mark and I discussed this offline, and decided there was no requirement
>> for the module to be preloaded. Do you have a different opinion?
> No, I was actually about to make the same point: it seems to me there
> are arguable use-cases for loading it shared, loading it per-session
> (perhaps via ALTER USER SET or ALTER DATABASE SET to target particular
> users/DBs), or even manually LOADing it.  So the module code should
> not be prejudging how it's used.
>
> On reflection, I withdraw my complaint about changing the way the
> test script loads the module.  Getting rid of the need for a custom
> .conf file simplifies the test module, and that seems good.
> So I'm on board with Mark's patch now.
>
>             



OK, I have pushed that.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: LockAcquireExtended() dontWait vs weaker lock levels than already held
Next
From: Andres Freund
Date:
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats