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

From Michael Paquier
Subject Re: New Object Access Type hooks
Date
Msg-id Yl0KI8WycbJ0eXqL@paquier.xyz
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  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Mar 24, 2022 at 05:44:31PM -0400, Tom Lane wrote:
> Note that that's basically a workaround for buggy placement of the
> OAT hooks, as per previous discussion.  I hope that we fix that bug
> pretty soon, so it shouldn't really be a factor for the meson conversion.

So, this issue is still listed as an open item.  What should we do?
From what I get, the caching issues with the namespace lookup hook are
not new to v15, they just get exposed by the new test module
test_oat_hooks/.  FWIW, I would vote against moving around hook calls
in back branches as that could cause compatibility problems in
existing code relying on them, but it surely is unstable to keep these
when recomputing the search_path.

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: pg_get_publication_tables() output duplicate relid
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication