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

From Andrew Dunstan
Subject Re: New Object Access Type hooks
Date
Msg-id e0538b66-8531-1000-52c9-5c0f61b8a71c@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  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 3/22/22 20:07, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 3/22/22 18:18, Tom Lane wrote:
>>> Now, if our attitude to the OAT hooks is that we are going to
>>> sprinkle some at random and whether they are useful is someone
>>> else's problem, then maybe these are not interesting concerns.
>> So this was a pre-existing problem that the test has exposed? I don't
>> think we can just say "you deal with it", and if I understand you right
>> you don't think that either.
> Yeah, my point exactly: the placement of those hooks needs to be rethought.
> I'm guessing what we ought to do is let the cached namespace OID list
> get built without interference, and then allow the OAT hook to filter
> it when it's read.
>
>> I could make the buildfarm quiet again by resetting NO_INSTALLCHECK
>> temporarily.
> I was able to reproduce it under "make check" as long as I had
> LANG set to one of the troublesome values, so I'm not real sure
> that that'll be enough.
>
>             


The buildfarm only runs installcheck under different locales/encodings.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New Object Access Type hooks
Next
From: Andres Freund
Date:
Subject: cpluspluscheck vs ICU