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 по дате отправления: