OCLASS_ROWSECURITY oversights, and other kvetching

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: OCLASS_ROWSECURITY oversights, and other kvetching
Date: 2014-10-07 16:14:26
Message-ID: CA+TgmobUs5HSNH9snFS6rrKa9C8rsOyo6=UaUXwQeaEuvf6GQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-10-07 16:24:29 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Ilya Kosmodemiansky 2014-10-07 15:05:41 Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)