Re: New Object Access Type hooks

On Mon, Apr 18, 2022 at 03:50:11PM +0900, Michael Paquier wrote:
> A removal from recomputeNamespacePath() implies an addition at the end
> of fetch_search_path() and fetch_search_path_array().  Perhaps an
> extra one in RangeVarGetCreationNamespace()?  The question is how much
> of these we want, for example the search hook would be called now even
> when doing relation-specific checks like RelationIsVisible() and the
> kind.

I have been playing with this issue, and if we want to minimize the
number of times the list of namespaces in activeSearchPath gets
checked through the search hook, it looks like this is going to
require an additional cached list of namespace OIDs filtered through
InvokeNamespaceSearchHook().  However, it is unclear to me how we can
guarantee that any of the code paths forcing a recomputation of
activeSearchPath are not used for a caching phase, so it looks rather
easy to mess up things and finish with a code path using an unfiltered
activeSearchPath.  The set of *IsVisible() routines should be fine, at
least.

At the end, I am not sure that it is a wise time to redesign this
area close to beta2, so I would vote for leaving this issue aside for
now.  Another thing that we could do is to tweak the tests and silence
the part around OAT_NAMESPACE_SEARCH, which would increase the coverage
with installcheck, removing the need for ENCODING and NO_LOCALE.
--
Michael