Re: New Object Access Type hooks

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: New Object Access Type hooks
Дата
Msg-id Yl0KI8WycbJ0eXqL@paquier.xyz
обсуждение исходный текст
Ответ на Re: New Object Access Type hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: New Object Access Type hooks  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: pg_get_publication_tables() output duplicate relid
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping schema changes in publication