OCLASS_ROWSECURITY oversights, and other kvetching

Поиск
Список
Период
Сортировка
От Robert Haas
Тема OCLASS_ROWSECURITY oversights, and other kvetching
Дата
Msg-id CA+TgmobUs5HSNH9snFS6rrKa9C8rsOyo6=UaUXwQeaEuvf6GQA@mail.gmail.com
обсуждение исходный текст
Ответы Re: OCLASS_ROWSECURITY oversights, and other kvetching
Список pgsql-hackers
The RLS patch added OCLASS_ROWSECURITY but it seems that not enough
effort was made to grep for places that might require adjustment as a
result.

In objectaddress.c, getObjectDescription() was updated, but
getObjectTypeDescription() and getObjectIdentity() were not.

In dependency.c, object_classes didn't get updated.

I also really question why we've got OCLASS_ROWSECURITY but
OBJECT_POLICY.  In most cases, we name the OBJECT_* construct and the
OCLASS_* construct similarly.  This is actually just the tip of the
iceberg: we've got OBJECT_POLICY but OCLASS_ROWSECURITY (no underscore
between row and security) and then we've got DO_ROW_SECURITY (with an
underscore) and pg_row_security.  But then on the other hand the
source code is in policy.c.  pg_dump tries to sit on the fence by
alternating between all the different names and sometimes combining
them (row-security policy).  Some places refer to row-LEVEL security
rather than row security or policies.

I think this kind of messiness makes code really hard to maintain and
should be cleaned up now while we have a chance.  For the most part,
we have chosen to name our catalogs, SQL commands, and internal
constants by *what kind of object it is* (in this case, a policy)
rather than by *the feature it provides* (in this case, row security).
So I think that everything relates to a policy specifically
(OCLASS_ROWSECURITY, pg_row_security, etc.) should be renamed to refer
to policies instead.  The references to row security should be
preserved only when we are talking about the table-level property,
which is actually called ROW SECURITY, or the feature in general.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Ilya Kosmodemiansky
Дата:
Сообщение: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL