[PATCH] Add reloption for views to enable RLS

Hi all!

As part of a customer project we are looking to implement an reloption 
for views which when set, runs the subquery as invoked by the user 
rather than the view owner, as is currently the case.
The rewrite rule's table references are then checked as if the user were 
referencing the table(s) directly.

This feature is similar to so-called 'SECURITY INVOKER' views in other DBMS.
Although such permission checking could be implemented using views which 
SELECT from a table function and further using triggers, that approach 
has obvious performance downsides.

Our initial thought on implementing this was to simply add another 
reloption for views, just like the already existing `security_barrier`. 
With this in place, we then can conditionally evaluate in 
RelationBuildRuleLock() if we need to call setRuleCheckAsUser() or not.
The new reloption has been named `security`, which is an enum currently 
only supporting a single value: `relation_permissions`.

The code for fetching the rules and triggers in RelationBuildDesc() had 
to be moved after the parsing of the reloptions, since with this change 
RelationBuildRuleLock()now depends upon having relation->rd_options 
available.

The current behavior of views without that new reloption set is unaltered.
This is implemented as such in patch 0001.

Regression tests are included for both the new reloption of CREATE VIEW 
and the row level security side of this too, contained in patch 0002.
All regression tests are passing without errors.

Finally, patch 0003 updates the documentation for this new reloption.

An simplified example on how this feature can be used could look like this:

   CREATE TABLE people (id int, name text, company text);
   ALTER TABLE people ENABLE ROW LEVEL SECURITY;
   INSERT INTO people VALUES (1, 'alice', 'foo'), (2, 'bob', 'bar');

   CREATE VIEW customers_no_security
       AS SELECT * FROM people;

   CREATE VIEW customers
       WITH (security=relation_permissions)
       AS SELECT * FROM people;

   -- We want carol to only see people from company 'foo'
   CREATE ROLE carol;
   CREATE POLICY company_foo_only
       ON people FOR ALL TO carol USING (company = 'foo');

   GRANT SELECT ON people TO carol;
   GRANT SELECT ON customers_no_security TO carol;
   GRANT SELECT ON customers TO carol;

Now using these tables as carol:

     postgres=# SET ROLE carol;
     SET

For the `people` table, the policy is applied as expected:

     postgres=> SELECT * FROM people;
      id | name  | company
     ----+-------+---------
       1 | alice | foo
     (1 row)

If we now use the view with the new relopt set, the policy is applied too:

     postgres=> SELECT * FROM customers;
      id | name  | company
     ----+-------+---------
       1 | alice | foo
     (1 row)

But without the `security=relation_permissions` relopt, carol gets to 
see data they should not be able to due to the policy not being applied, 
since the rules are checked against the view owner:

     postgres=> SELECT * FROM customers_no_security;
      id | name  | company
     ----+-------+---------
       1 | alice | foo
       2 | bob   | bar
     (2 rows)


Excluding regression tests and documentation, the changes boil down to this:
  src/backend/access/common/reloptions.c    | 20
  src/backend/nodes/copyfuncs.c             |  1
  src/backend/nodes/equalfuncs.c            |  1
  src/backend/nodes/outfuncs.c              |  1
  src/backend/nodes/readfuncs.c             |  1
  src/backend/optimizer/plan/subselect.c    |  1
  src/backend/optimizer/prep/prepjointree.c |  1
  src/backend/rewrite/rewriteHandler.c      |  1
  src/backend/utils/cache/relcache.c        | 62
  src/include/nodes/parsenodes.h            |  3
  src/include/utils/rel.h                   | 21
  11 files changed, 84 insertions(+), 29 deletions(-)

All patches are against current master.

Thanks,
Christoph Heiss