On Mon, Mar 16, 2015 at 8:10 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > (Note there is some bitrot in gram.y that prevents the first patch > from applying cleanly to HEAD)
That's trivially fixable. I'll have those fixes in the next revision, once I firm some things up with Heikki. > I tested using the attached script, and one test didn't behave as I > expected. I believe the following should have been a valid upsert > (following the update path) but actually it failed: > > INSERT INTO t1 VALUES (4, 0) ON CONFLICT (a) UPDATE SET b = 1; > > AFAICT, it is applying a WITH CHECK OPTION with qual "b > 0 AND a % 2 > = 0" to the about-to-be-updated tuple (a=4, b=0), which is wrong > because the "b > 0" check (policy p3) should only be applied to the > post-update tuple. > > Possibly I'm missing something though. I think that you may have. Did you read the commit message/docs of the RLS commit 0004-*? You must consider the second point here, I believe: """" The 3 places that RLS policies are enforced are: * Against row actually inserted, after insertion proceeds successfully (INSERT-applicable policies only). * Against row in target table that caused conflict. The implementation is careful not to leak the contents of that row in diagnostic messages (INSERT-applicable *and* UPDATE-applicable policies). * Against the version of the row added by to the relation after ExecUpdate() is called (INSERT-applicable *and* UPDATE-applicable policies). """" You're seeing a failure that applies to the target tuple of the UPDATE (the tuple that we can't leak the contents of). I felt it was best to check all policies against the target/existing tuple, including both WITH CHECK OPTIONS and USING quals (which are both enforced). I can see why you might not like that behavior, but it is the intended behavior. I thought that this whole intersection of RLS + UPSERT is complex enough that it would be best to be almost as conservative as possible in what fails and what succeeds. The one exception is when the insert path is actually taken, since the statement is an INSERT statement. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers