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

From Andrew Dunstan
Subject Re: New Object Access Type hooks
Date
Msg-id f359d309-b4f6-9d21-4af2-f064d77ab4a8@dunslane.net
Whole thread Raw
In response to Re: New Object Access Type hooks  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: New Object Access Type hooks  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 3/22/22 20:11, Andrew Dunstan wrote:
> 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.


But you're right about the non-installcheck cases. fairywren had that
issue. I have committed a (tested) fix for those too to force
NO_LOCALE/UTF8.


cheers


andrew


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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Use JOIN USING aliases in ruleutils.c
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Implement INSERT SET syntax