Re: New Object Access Type hooks
От | Andrew Dunstan |
---|---|
Тема | Re: New Object Access Type hooks |
Дата | |
Msg-id | f359d309-b4f6-9d21-4af2-f064d77ab4a8@dunslane.net обсуждение исходный текст |
Ответ на | Re: New Object Access Type hooks (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: New Object Access Type hooks
|
Список | 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 по дате отправления: