*** /home/jeevan/work/pg_master/src/test/regress/expected/rowsecurity.out	2016-09-26 12:02:39.441180664 +0530
--- /home/jeevan/work/pg_master/src/test/regress/results/rowsecurity.out	2016-09-26 17:21:21.765346445 +0530
***************
*** 1643,1699 ****
  -- updated is not a "novel"/cid 11 (row is not leaked, even though we have
  -- SELECT privileges sufficient to see the row in this instance):
  INSERT INTO document VALUES (33, 22, 1, 'regress_rls_bob', 'okay science fiction'); -- preparation for next statement
  INSERT INTO document VALUES (33, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'Some novel, replaces sci-fi') -- takes UPDATE path
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle;
! ERROR:  new row violates row-level security policy (USING expression) for table "document"
  -- Fine (we UPDATE, since INSERT WCOs and UPDATE security barrier quals + WCOs
  -- not violated):
  INSERT INTO document VALUES (2, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'my first novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
!  did | cid | dlevel |     dauthor     |     dtitle     
! -----+-----+--------+-----------------+----------------
!    2 |  11 |      2 | regress_rls_bob | my first novel
! (1 row)
! 
  -- Fine (we INSERT, so "cid = 33" ("technology") isn't evaluated):
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
!  did | cid | dlevel |     dauthor     |        dtitle         
! -----+-----+--------+-----------------+-----------------------
!   78 |  11 |      1 | regress_rls_bob | some technology novel
! (1 row)
! 
  -- Fine (same query, but we UPDATE, so "cid = 33", ("technology") is not the
  -- case in respect of *existing* tuple):
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
!  did | cid | dlevel |     dauthor     |        dtitle         
! -----+-----+--------+-----------------+-----------------------
!   78 |  33 |      1 | regress_rls_bob | some technology novel
! (1 row)
! 
  -- Same query a third time, but now fails due to existing tuple finally not
  -- passing quals:
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
! ERROR:  new row violates row-level security policy (USING expression) for table "document"
  -- Don't fail just because INSERT doesn't satisfy WITH CHECK option that
  -- originated as a barrier/USING() qual from the UPDATE.  Note that the UPDATE
  -- path *isn't* taken, and so UPDATE-related policy does not apply:
  INSERT INTO document VALUES (79, (SELECT cid from category WHERE cname = 'technology'), 1, 'regress_rls_bob', 'technology book, can only insert')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
!  did | cid | dlevel |     dauthor     |              dtitle              
! -----+-----+--------+-----------------+----------------------------------
!   79 |  33 |      1 | regress_rls_bob | technology book, can only insert
! (1 row)
! 
  -- But this time, the same statement fails, because the UPDATE path is taken,
  -- and updating the row just inserted falls afoul of security barrier qual
  -- (enforced as WCO) -- what we might have updated target tuple to is
  -- irrelevant, in fact.
  INSERT INTO document VALUES (79, (SELECT cid from category WHERE cname = 'technology'), 1, 'regress_rls_bob', 'technology book, can only insert')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
! ERROR:  new row violates row-level security policy (USING expression) for table "document"
  -- Test default USING qual enforced as WCO
  SET SESSION AUTHORIZATION regress_rls_alice;
  DROP POLICY p1 ON document;
--- 1643,1684 ----
  -- updated is not a "novel"/cid 11 (row is not leaked, even though we have
  -- SELECT privileges sufficient to see the row in this instance):
  INSERT INTO document VALUES (33, 22, 1, 'regress_rls_bob', 'okay science fiction'); -- preparation for next statement
+ ERROR:  new row violates row-level security policy for table "document"
  INSERT INTO document VALUES (33, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'Some novel, replaces sci-fi') -- takes UPDATE path
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle;
! ERROR:  new row violates row-level security policy for table "document"
  -- Fine (we UPDATE, since INSERT WCOs and UPDATE security barrier quals + WCOs
  -- not violated):
  INSERT INTO document VALUES (2, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'my first novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- Fine (we INSERT, so "cid = 33" ("technology") isn't evaluated):
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- Fine (same query, but we UPDATE, so "cid = 33", ("technology") is not the
  -- case in respect of *existing* tuple):
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- Same query a third time, but now fails due to existing tuple finally not
  -- passing quals:
  INSERT INTO document VALUES (78, (SELECT cid from category WHERE cname = 'novel'), 1, 'regress_rls_bob', 'some technology novel')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle, cid = 33 RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- Don't fail just because INSERT doesn't satisfy WITH CHECK option that
  -- originated as a barrier/USING() qual from the UPDATE.  Note that the UPDATE
  -- path *isn't* taken, and so UPDATE-related policy does not apply:
  INSERT INTO document VALUES (79, (SELECT cid from category WHERE cname = 'technology'), 1, 'regress_rls_bob', 'technology book, can only insert')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- But this time, the same statement fails, because the UPDATE path is taken,
  -- and updating the row just inserted falls afoul of security barrier qual
  -- (enforced as WCO) -- what we might have updated target tuple to is
  -- irrelevant, in fact.
  INSERT INTO document VALUES (79, (SELECT cid from category WHERE cname = 'technology'), 1, 'regress_rls_bob', 'technology book, can only insert')
      ON CONFLICT (did) DO UPDATE SET dtitle = EXCLUDED.dtitle RETURNING *;
! ERROR:  new row violates row-level security policy for table "document"
  -- Test default USING qual enforced as WCO
  SET SESSION AUTHORIZATION regress_rls_alice;
  DROP POLICY p1 ON document;
***************
*** 3443,3448 ****
--- 3428,3434 ----
  ALTER TABLE r1 FORCE ROW LEVEL SECURITY;
  -- Works fine
  INSERT INTO r1 VALUES (10), (20);
+ ERROR:  new row violates row-level security policy for table "r1"
  -- No error, but no rows
  TABLE r1;
   a 
***************
*** 3473,3484 ****
  ALTER TABLE r1 FORCE ROW LEVEL SECURITY;
  -- Works fine
  UPDATE r1 SET a = 30;
  -- Show updated rows
  ALTER TABLE r1 NO FORCE ROW LEVEL SECURITY;
  TABLE r1;
   a  
  ----
!  30
  (1 row)
  
  -- reset value in r1 for test with RETURNING
--- 3459,3471 ----
  ALTER TABLE r1 FORCE ROW LEVEL SECURITY;
  -- Works fine
  UPDATE r1 SET a = 30;
+ ERROR:  new row violates row-level security policy for table "r1"
  -- Show updated rows
  ALTER TABLE r1 NO FORCE ROW LEVEL SECURITY;
  TABLE r1;
   a  
  ----
!  10
  (1 row)
  
  -- reset value in r1 for test with RETURNING

======================================================================