Re: refactor ownercheck and aclcheck functions

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: refactor ownercheck and aclcheck functions
Дата
Msg-id CADkLM=dYg3urxeycJFpMRgTCPYk7=04R0CrJoC-qGOLBptWB+g@mail.gmail.com
обсуждение исходный текст
Ответ на refactor ownercheck and aclcheck functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: refactor ownercheck and aclcheck functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
On Fri, Oct 14, 2022 at 3:39 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
These patches take the dozens of mostly-duplicate pg_foo_ownercheck()
and pg_foo_aclcheck() functions and replace (most of) them by common
functions that are driven by the ObjectProperty table.  All the required
information is already in that table.

This is similar to the consolidation of the drop-by-OID functions that
we did a while ago (b1d32d3e3230f00b5baba08f75b4f665c7d6dac6).

Nice reduction in footprint!

I'd be inclined to remove the highly used ones as well. That way the codebase would have more examples of object_ownercheck() for readers to see. Seeing the existence of pg_FOO_ownercheck implies that a pg_BAR_ownercheck might exist, and if BAR is missing they might be inclined to re-add it.

If we do keep them, would it make sense to go the extra step and turn the remaining six "regular" into static inline functions or even #define-s?

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ts_locale.c: why no t_isalnum() test?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Logical WAL sender unresponsive during decoding commit