Re: oat_post_create expected behavior

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: oat_post_create expected behavior
Дата
Msg-id 953223.1654549879@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: oat_post_create expected behavior  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: oat_post_create expected behavior  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 6, 2022 at 1:35 PM Jeff Davis <pgsql@j-davis.com> wrote:
>> Out of curiosity, why not? The proposed patch only runs it if the
>> object access hook is set. Do you see a situation where it would be
>> confusing that an earlier DDL change is visible? And if so, would it
>> make more sense to call CCI unconditionally?

> Well, I think that a fair amount of work has been done previously to
> cut down on unnecessary CCIs. I suspect Tom in particular is likely to
> object to adding a whole bunch more of them, and I think that
> objection would have some merit.

We've gotten things to the point where a no-op CCI is pretty cheap,
so I'm not sure there is a performance concern here.  I do wonder
though if there are semantic or bug-hazard considerations.  A CCI
that occurs only if a particular hook is loaded seems pretty scary
from a testability standpoint.

> I definitely think if we were going to do it, it would need to be
> unconditional. Otherwise I think we'll end up with bugs, because
> nobody's going to go test all of that code with and without an object
> access hook installed every time they tweak some DDL-related code.

Right, same thing I'm saying.  I also think we should discourage
people from doing cowboy CCIs inside their OAT hooks, because that
makes the testability problem even worse.  Maybe that means we
need to uniformly move the CREATE hooks to after a system-provided
CCI, but I've not thought hard about the implications of that.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How about a psql backslash command to show GUCs?
Следующее
От: David Rowley
Дата:
Сообщение: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list